Oredev Conference - Day 2 2024
Yet again I had another fantastic day at Öredev powered by way too much coffee and candy.
If you haven’t already, be sure to check out my blog post from my first day at the Öredev conference. After this one, be sure to read my write-up on the last day of the Öredev conference.
I did a much better job of taking notes this time around, so let’s get into it.
We’re Good At Writing Software
Beth Andres-Beck and Kent Beck gave the opening keynote where they explored the idea of building software in a forest or a desert.
My understanding was that a metaphor of a forest is where a development team can thrive. Whereas it is difficult for development teams to thrive in a desert.
The talk was centred around this theme, where Andres-Beck and Beck shared the foundation of building a forest/planting trees and then what the signs look like.
What can lead to no bugs in prod?
- Tests (alignment of responsibility if you can break it, you can fix it) Tests coupled with the behaviour of the code but decoupled from the structure of the code
- Incremental design. Make the change easy, then make the easy change. (In deserts, change is hard. In forest changes are easy.)
- Teaming. Not afraid of conflict and engaging with team members. In the forest we don’t need to get decisions right the first time to succeed.
Great signs
- Experiments - people can try things
- Customer present. You can engage with your customers, get feedback etc.
- We have time to teach people well. To gain the skills needed to get tasks done. People not thrown into the deep end unnecessarily
- Demos are present. (In deserts, people wouldn’t have anyone to present demos to, since you are shielded from the stakeholders who would’ve been the target audience of the demos)
- In the desert, people don’t like to talk about consequences. Eg. What happens if you miss the deadline?
“We have alignment because we have the same information.”
- Beth Andres-Beck
“The feedback we have on whether we are in the dessert or forest is our feelings. In the forest we feel joy. In the desert we feel anxiety; imposter syndrome.”
- Beth Andres-Beck
Facilitate You! - Use your facilitating skills to lead yourself
Martin Mazur tackled the topic of self-leadership and using facilitating skills to lead yourself.
“All the freedom I had to do whatever I want was actually quite crippling. I had to set up guardrails for myself.”
- Martin Mazur
Typically, there are more opportunities to lead than for people to lead.
Often people may be good leaders to others, but they don’t extend that care/skills to themselves.
Another way to put it: The shoemaker’s children always go barefoot. Meaning: Often those closest to a person don’t benefit from the person’s expertise.
Mazur reminded us that we need to remember that you are also a stakeholder to yourself.
He then told us we should ask ourselves the following: If you managed yourself, would you quit?
“Regardless of what I discover, I understand and truly believe that I did the best job I could, given what I knew at the time, my skills and abilities, the resources available, and the situation at hand.”
- Martin Mazur
Self-leadership
You don’t need to learn new skills. You just need to apply these skills to yourself as well (not just others).
Avoid productivity theatre
i.e. Doing the easy things and keeping busy. But not actually creating the value you wanted to create.
This can result from not knowing what your goal is; what your North Star is.
Too busy sharpening the saw
Spending too much time trying to find the best way to do something. Or preparing. But then not actually DOING the thing
Leading you, by you
Past-you should be your best friend. Do things today that help make things easier for your future you.
Personal workshops
- Daily check in (like a daily standup) Night before he writes the following questions:
- What went well yesterday?
- What is my priority today?
- Is there any work “not to be done”?
Mazur isn’t necessarily recommending these are the questions others should ask themselves - just that these are the ones he asks himself.
- Weekly planning (These can give him some structure.)
Mazur also went a bit into personal retros and how he has found them beneficial.
Call to Connection: Cultivating Quality Relationships with Diverse Personalities
Lorraine Williams taught us how understanding each other’s different personalities can help us work better together.
“If you have direct reports, it is your responsibility to make sure you can communicate well.”
- Lorraine Williams
We need to learn how to show vulnerability, how to be curious and how to handle uncertainty. Need to give feedback - both when they are doing something well and when something needs to be corrected.
Personality profiles/assessments
There is value not just from seeing what you get but also seeing what others get. It can help you understand others better, see what their preferences are.
Emotional Triggers
Can cause us to Armor-up, place us in a “Box of Self-Deception and… create Cycles of Collusion
We normally don’t see ourselves as others see us.
Williams then explains then we each see the world through our own lens, which is self-limiting. What influences this includes:
- Experiences
- Age
- Gender
- Where I live etc.
One’s lens is used to judge other people.
By its very nature, one’s lens is distorted.
Assume best intent
- Remember there is power in the pause. If you don’t pause. Then you are more likely to act on default.
- Start with the most generous interpretation you can
- Remind yourself, you are using a very different lens than they are
- you do not know their “why”
Own your part
- Do l inadvertently feed this person’s attitude or behaviors?
- Might I somehow bait them with my words or tone?
- Am I closed down when we interact?
- What assumptions am I making that need further investigation?
Unlocking Agile Potential: The Role of Quality Coaches
Gitte Ottosen went into why quality coaches are becoming more popular and what it is they actually do.
Some roles are disappearing. Eg. Test manager and tester.
The work the test manager did(do) is still around. Eg. Coming up with test strategy, test plans etc.
For the past few years, Gitte has been on projects where they don’t have testers.
T shaped testers. Then asking for skills and multiple depth. The more competences you want to have in one person- the less depth you get.
Ottosen gave a shoutout to Anne-Marie Charrett. Everything Ottosen does when it comes to quality coaching is based on Charretts work. She also recommended Charrett’s Quality Coaching book.
Ottosen told us we need to think about our approach when it comes to risk-based testing. Can you explain the red thread? Can you tell the story around your approach?
How can we tailor our approach to testing that gives us fast continuous feedback?
Data combinations
Need to have dialogue with stakeholders about what quality means to them
” We need to think not just about what we are measuring but why we are measuring it."
- Gitte Ottosen
How hacking works - Web edition
Espen Sande Larsen explained how hacking works (and how it doesn’t with the use of some nice videos) as well as some live demos.
What is hacking?
- It used to mean tinkering with software and electronics (make it do something it wasn’t originally intended to do)
- Think outside the box
What we call “hacking” today used to be call “Phreaking” Exploiting systems to show their vulnerabilities
Why do hacks happen?
- Because people make mistakes.
- Devil is in the overlooked details
- Trusting other people’s code
- Over reliance on certain tools
How can we prevent hacks?
CTF/Hacker Olympics (Capture The Flag)
- It’s a gamified way to learn adversial techniques
- Enables you to think differently
- Solving challenges
- Creates engagement and conversations
Some examples of CTFs:
- HackTheBox
- TryHackMe
- picoCTF
- Google CTF
- JuiceShop
- Hack The Bank
- Defcon
- Blackhat
Web exploits
- XSS
- SQL Injection
- Template Poisoning
- Prototype Pollution
- Misconfiguration
- Broken Authentication
- Phishing-Spear Phishing
- 3rd party vulnerabilities
Larsen finished things off with a few demos where he shows us how he hacks and talked us through his thought process. One thing I remember him saying was that a 404 or other web page (or looking at the dev console) can tell you info about what was used to build the web page. You can then look up known vulnerabilities related to what was used to build that webpage.
TRIM Your Automated Tests
While I had already been to Richard Bradshaw’s Automation In Testing workshop which covered some of these concepts. I felt like I needed a wee refresher as it had been over 5 years. (And FWIW highly recommend! Follow him online to stay tuned for any possible upcoming workshops)
“Too many tests are automated too high up the tech stack and too far from the risk they are supposed to mitigate.”
- Richard Bradshaw
“Too many tests exists that could now be deleted, because either the risk is no longer there, or the risk is being mitigated by a different test.”
- Richard Bradshaw
Why Bradshaw thinks this happens:
- Plethora of tooling for the Ul layer
- Testers are more comfortable on the Ul
- Fixation on automating stories/e2e
- Poor technical system understanding
- Lack of tralning away from the Ul
- A willingness from some developers to do testing ( beyond unit testing, or even to do unit testing!)
- Poor collaboration between testers and QAs/QEs
- Legacy test suites
- Traditional test approaches
These problems can lead to:
- Slow feedback from tests
- Slower time to production
- Test brittleness
- Test data management
- Increased time to debug failing tests
- Unwillingness to delete tests
- Divide between testing efforts
Bradshaw came up with a useful pen and paper model we can utilise.
TRIMS
- Targeted
- Reliable
- Informative
- Mintainable
- Speedy
Targeted
Targeted to a specific risk and automated on the lowest layer the testability allows.
Think:
- Risk
- Actor
- Layer
- Testability
Reliable
Test your tests
- Run them multiple times
- Reverse your assertions (make sure the test can actually fail)
- Manipulate the app to see it can fail
- Flakiness - larger the test, larger the risk
To maximise their value, tests need to avoid intentional flakiness, we need them to be deterministic.
Think:
- Determininitic
- Mean time to feedback MTF
Informative
Passing and failing tests need to provide as much info as possible to aid exploration.
Naming Tests - Avoid Certain Words
- Should
- Be assertive, describe the actual behaviour
- Can / Valid / Invalid / Good / Bad
- Be more specific
- Test
- Unless the test framework requires it we already know It’s a test.
Test Output A failing test is an invitation to explore Speed up the process by automatically collating artefacts to aid the exploration, provide the context. e.g. Logs, Screenshots, Videos, Data Dur Traces and so forth.
Think:
- Debugging
- Explorarion
- Decision-making
Maintainable
automated tests are subject to constant change so we need a high level of maintainability.
Design Patterns
- Screenplay
- Page Objeets
- AAA (Arrange, Act, Assert)
- Data Builder Pattern
Test Complexity
- Avoid conditionals
- Just add more tests
- Focus on readability
- Simplicity is key
Think:
- Design
- Clean code
- Good practises
Speedy
Creation, execution and maintenance need to be as fast as the testability allows to achieve rapid feedback loop
