Lee Hawkins

Are Your Retros a Waste of Time? I recently attended a retrospective where the team was seriously disengaged. Like, silent. Afterwards, I asked the developers why, and they said "We're disengaged because this meeting isn’t valuable." I said, "I think you've got that backwards. The retro isn't valuable because you’re disengaged!" Retros are a core Scrum event. Teams have a chance to reflect, adapt, and grow. When done well, they encourage accountability and improvement. But when they fail, they just a chore. Let's revisit the purpose of retros and see where teams go wrong. Purpose The purpose of a retro is to reflect on the ending sprint, identify what worked and what didn’t, and decide on improvements. It’s not about rehashing, but learning. A successful retro strikes a balance between celebrating successes and addressing challenges. The team should leave energized, motivated, and ready to adapt. Where Retros Go Wrong Retros fail when teams drift from their purpose, team members don’t feel safe sharing honest feedback, discussions are superficial, and real issues are ignored. Some teams focus too much on the negative, turning retros into morale-killing complaint sessions. Others waste the meeting congratulating themselves instead of acknowledging problems. Neither approach leads to improvement. Then there are vague or unrealistic action items. Goals like “improve communication” sound good but no one knows what that really means, so... no change. Disengagement is another challenge. Teams mistake it as proof the retro isn’t valuable, but it’s the other way around. Disengagement causes ineffective discussions, creating a vicious cycle. Lack of follow-through undermines the whole exercise. Without accountability, retros lose credibility and the team just repeats the same mistakes. Refocus to Reclaim Retros First, create a safe environment for open dialogue. Leaders and facilitators should model vulnerability and keep discussions focused on issues, not people. Celebrate successes, but dive into challenges with an honest intent to improve. This balance keeps retros positive and productive. Make action items specific, measurable, and realistic. Aim for clarity, like “schedule a five-minute daily sync to address blockers.” I’m not going to recommend retro formats, because you can Google a googol of them, and the format matters far less than the conversation. There are tools, though, that may help - like Parabol, Retrium, and EasyRetro. Jira users might try TeamRetro or Agile Retrospectives. These tools provide templates, prompts, and visual boards that can really help. Experiment to find what works best. Oh... and close the loop on action items. Start each retro by reviewing progress on past improvements, and you'll reinforce accountability. Stop Wasting Time If retros feel like a waste of time, you may have strayed from their purpose. Retros aren't inherently valuable; they only become valuable when teams engage, reflect, and act.

25

10 Comments

A Word of Caution: Accuracy Matters No matter how keen you are to upsell yourself never add inaccurate information to your CV or job description. Misrepresenting your experience can lead to a swift loss of credibility and trust, especially in public roles. Stay honest and transparent about your qualifications. What are your thoughts on maintaining credibility in professional settings? Have you encountered similar situations?

1

💡 To all QA Managers/Head of Test – How NOT to lose your key testers to competition in 2024. After speaking with thousands of testers over the years, and having personally placed hundreds of QA/Testers in Sydney alone – I have listened to what makes them happy, and importantly what doesn’t make them happy. I take this information and feedback very seriously from them, and I always advise hiring managers of the incumbents requirements, ensuring they will be fully committed to a new role when offered.. The feedback was: 1. Ensuring work life balance was available – 90% of the testers I spoke to did NOT want to go into the office every day. WFH options in 2024 is mandatory. 2. The company has structure, a good environment and Progression plans. 3. Growth – For example Junior to Mid level testers want a company that offers training, mentoring and coaching – so they can learn adequately from more senior people. 4. Senior Testers are more about the Challenge, and interesting projects on offer. 5. The money has to be there, for example: If you’re hiring a Senior Automation Tester, you cant skimp out and offer them a mid-range salary/daily rate.. They will leave once they receive a better offer, which aligns with their experience. 6. Job stability – A Full Time QA Tester is not going to leave their current role unless the new role and work on offer is stable and plentyfull. 7. Incentives and bonuses is a BIG one, knowing you can potentially earn more at your job is a MASSIVE plus. 8. Recognition and Appreciation – these go a long way to ensure Testers feel comfortable in their job. To my Test Network - If there are any further inputs you can think of, I would love to hear your advice and further pointers to help.. Best regards, Rob

546

22 Comments

Here's our next Ministry Of Testing - Auckland meetup Join us for retelling of Spark New Zealand's journey into the world of Playwright by Glen Osborne. Spark’s transformation from manual to automated testing using a custom playwright framework has been interesting. The automation journey for me was going from automation in the CI/CD world to automation in the testing world. We often look for tools that tick all the right boxes when we should look for the right tool and modify it for our use cases. Playwright for end-to-end testing is a solution that our people got excited about and proved to be the correct choice for the business. https://lnkd.in/gZ54Fu6G btw we're looking for a sponsor of our drinks and pizzas, if your company has about $200 in their PR budget and would like to connect with 50-100 Quality and Automation Engineers then please do reach out. <below is me asking chatGPT to give me some hashtags> #TestingCommunity #AutomationTesting #Playwright #QualityAssurance #SoftwareTesting #TechMeetup #AucklandTech #MinistryOfTesting #TestAutomation #QACommunity #EndToEndTesting #ContinuousTesting #CICDAutomation #TechEvent #SponsorshipOpportunity

36

Is this meme situation truly happening in your companies? This appears to be the result of a flawed QA/development process or relationship, which should never occur. It's akin to homophobic behaviour. Why might the lead not want the tester to report a bug? If there's a process for bug severity and prioritisation, then reporting it is the best course of action. Later, a decision can be made on whether to fix it before release, after, or perhaps even never. If the relationship with a client is properly established, then reporting bugs should be a normal part of the development process. It's possible that this is yet another critical bug, and the client is already frustrated – indicating an ongoing issue with software quality. I wonder how many memes are out there that seem like a perfectly normal part of the IT world, but beneath the surface reveal serious malfunctions we may have come to accept.

4

I recently wrote a few posts about the importance of automation testing.Yesterday someone commented under one of them saying that all these tests are now "obsolete". Apparently, there is a "new global trend" where everyone is moving into using AI to test their software instead of writing those "obsolete" unit tests, integration tests, etc. Of course, it made me spill my coffee when someone is talking about an alleged global trend and he was literally the first person I've heard suggesting this 😁 However, it made me think of the use cases of AI for automation testing. Yes, you absolutely can (and should) use AI for automation testing, but not in the way this person suggested. The biggest use cases for AI are the following: - Use it to write tests for you. However, your pipeline will still rely on written tests and not the AI. And you absolutely must verify all those tests afterwards. - Use it for penetration testing against a deployed app. It will come up with some scenarios you didn't think of and it may as well be able to remove the need for hiring external penetration testers. But you absolutely can't use AI as your primary test suit. You can't rely on something that is inconsistent, not 100% reliable, and is prone to hallucinations. Also, if you are developing anything that isn't just a basic calculator app, having a lower-level unit and integration tests helps you to receive early feedback if something goes wrong. You can apply the necessary fixes right away. You won't have to wait until the software is already in pre-production to discover that something is wrong with it and delay the release in the process.

11

5 Comments

MFAT bungles an IT Project. The Business of Tech is a great wee find. However, this morning it felt like a re-run of the early 2000’s. How did a $12M Capex and $0.9M Opex turn into a $33M mess? A review by PWC’s is a damning. This is summarised on page 12 in a little red box which says that any delivery is ‘highly unlikely’ to happen. So that $33M is not the end of the discussion, there will be more money, consultants and heads rolling here. No wonder confidence is low when considering technology projects and Government initiatives in general. There is some great ‘learnings’ in this report, but when do ‘learnings’ become doings? While a toxic culture seems to have played a part here, it should never have continued. Read the report, listen to the pod. Love to hear your hot takes…. In the meantime I’m left pondering why ‘Teams Lite’ is a good enough outcome for our Government departments…. https://lnkd.in/gCAap4Qd

8

12 Comments

Your dev team is under resourced Spoiler - it always will be Don't get trapped thinking if you just had two more (or fifty more) devs you'd be able to work through the backlog and get ahead. The problem is that teams try and filter and prioritise *down stream* on outputs. 100's of outputs. Try filtering and prioritising *up stream* on strategic outcomes that matter to the business (and across the business).

12

9 Comments

Is it really a talent shortage - or just time to rethink the way you hire? Top developers & PMs are favouring the flexibility of contract roles over the rigidity of traditional full-time gigs. So why keep chasing the "perfect" hire when there’s a skilled contract workforce ready to jump in and deliver from day one? we are djr 🔵⚪ #talentshortage #developers #recruitment

11

1 Comment

"I have a tendency to find fault. If something is out of place, it screams at me. When your tendency becomes your job and you are paid for it, it’s perfect, isn't it?" This was the response from a QA Engineer when I asked what they like about their work during a recent interview. We both burst out laughing. Somewhere, a group of Dev Engineers probably dropped their coffee, sensing a wave of bug reports. 😅 #QualityAssurance #DeveloperLife #TechHumor #InterviewTales #SoftwareTesting #Debugging #CodeQuality #QAEngineer #SoftwareDevelopment #WorkplaceHumor #FunFriday

19

3 Comments

Thank you very much for the signal boost, Steve; and I join you in thanking Ryan Bevens (and Tim Cooke) at Potentia and Pete Savage at Resourcefully.io for organizing everything. Looking forward to the classes — Testers and Automation: Avoiding the Traps; and Rapid Software Testing Explored. Note that since Testing Is Everybody's Responsibility now, sharpening everybody's testing skill is de rigeur, so these classes are Not For Testers Only. They're for anyone who needs to learn about products quickly; to determine where deep testing needed and shallow testing might do; and tp find important problems before it's too late. That includes testers, for sure, but it also includes developers, operations folk, technical and customer support people, managers... anyone who needs to do testing, or to manage or benefit from testing work. Apropos of that, here's an experience report from Sebastian Wuoma, head of the Head of the B2C System Team at Telia in Finland. He's been been applying RST at his organization since he took the class last year. And, you know, managers... with yet another Christmas *just* around the corner, what better present for your people than a few days in an educational, practical, and fun class?

10

Aside from automation skills that seem to sought after by most within QA + the ever evolving topic around AI, there's plenty of other ways of working/testing techniques that I hear mentioned consistently. - TDD, BDD, shift left, contract testing - to name a few.. Considering we're in a time that is so, so competitive - the last thing QA/QE people want, is to be working in a way that isn't sought after when they look for a change. If you were a junior starting out in your QA journey - what are the techniques/methodologies you'd focus on most? #QA #QualityEngineering

20

15 Comments

If you’ve ever worked with end-to-end testing frameworks, you’re likely familiar with the frustration of brittle tests tightly coupled to implementation details. Whilst we endeavor to minimize this, some coupling between test and implementation detail is often unavoidable, and this can lead to tests that are prone to break from small, irrelevant, and non-functional changes to the UI, whilst the behavior is still working as expected. Brittle tests have great potential to introduce unnecessary delays in release cycles. This happens because end-to-end tests are broad in scope, and it’s impossible to know if the rest of the functionality works as expected if a test fails early in the process. This is especially burdensome as E2E tests are often performed late in a release cycle due to their high cost. For this reason, the developer feedback loop can be significantly hampered, and the maintenance cost can be substantial. Large Language Models (LLMs) offer a promising solution to this inherent problem. Test cases can be defined at a high level, and then LLMs can dynamically interpret the DOM at runtime, creating appropriate test scripts based on the current state of the UI and the test objective. This means that anyone, regardless of their programming skills, can write these test cases. Instead of relying on implementation details, these tests interact with the UI like a user would and determine the most appropriate way to test the current version of the UI based on test requirements, thus avoiding all unnecessary coupling to implementation details. While there is some inherent complexity in such a solution, such as the context size of the HTML representation of the DOM and other challenges notably around performance, the potential for more robust and adaptable testing is significant. I have seen promising results from optimization techniques such as Retrieval-Augmented Generation (RAG) search on a custom render tree representation of the DOM, enhanced with computer vision classification of bounding boxes. Given the success of universal scraping solutions leveraging LLMs, the idea of stable end-to-end tests might just be within our grasp. Imagine a future where end-to-end test cases are so robust that they not only survive multiple iterations of a UI but could even operate across platforms where the functionality is the same, such as testing the search functionality of different search engines. This prospect invites us to reconsider not just how we test, but the very resilience and adaptability of our testing frameworks, making them accessible to a broader range of contributors. #Testing #EndToEnd #LLMs #Automation #SoftwareDevelopment #AI

3

I've been doing tech recruitment for a really long time. I'm a huge advocate of getting on the phone and calling people - yes I'm one of those that eats the phone all day long and love it. It's taken me a seriously long time to actually start posting regularly and feel comfortable conveying my / beaumont's message to the market we recruit into. Some people I'm trying to work with - candidates and clients, will like it, some won't and some won't care. Regardless of the fact it's given me some success (if you are another recruiter in my market reading this then I'm lying - doesn't work AT ALL 👀), I still get self-conscious about posts, seeing my face on LinkedIn and even more so with video. Let's be honest, haters are always going to hate, view your LinkedIn profile and make comments. This quote comes to mind. "The only reason people talk about you behind your back is because you are already ahead of them." Getting a message like this from a Chief Revenue Officer who wants our assistance helps reinforce that the message is being received loud and clear. whoisrepresentingyourcareer? whoisrepresentingyourbusiness?

15

2 Comments

Why does software so often fail where it matters most—out in the wild? It is a well known fact (or it should be) that developers don´t make good testers.  In fact, developers are terrible testers. A truth I have learnt the hard way, over the years, working at projects with tight budgets, where someone wearing the "guy in charge of testing" hat is just an unaffordable commodity. As outdated it may sound, I have come to believe that it happens more often than not, and that PMs, often come up with creative, yet sketchy ways to circumvent it ...or with nothing in tow at all, and let´s see what happens. The result is often shipping code that fails the mighty fail when the end user does anything that strays the slightest form the happy path. Fault-tolerance goes down the drain. And, as much as there are people coming up with funny ways to avoid having someone dedicated exclusively to testing, there is a certain amount of brainy explanations behind the good old "it works on my machine" rap. I would argue that the most common of all biases that developers bring into crafting and developing code is what is called confirmation bias, which means that, as a developer carrying out a certain developement task you may tend to tunnel your focus and vision on the expected behaviour of what you are building and not on what could go wrong. Or what could happen if this and that happen to go wrong at the same time. And the list of unexpected circumstances that may converge at a point in time could go on forever. All this, at the end of the day, is a natural thing, as, coming up with secondary cases, error cases, corner cases and things that close to never come described in any requirement spec whatsoever, takes a considerable amount of extra effort. And its unlikely that someone is going to take the high road if none of that was demanded by a stakeholder in the first place. Then there is the thing about unit tests. TDD practices aside, more often that not its developers who are expected to write their own unit and integrations tests. This, the way I see it, often leads to those tests being subjected to that same confirmation bias, as one may often end up writing unit tests that test how the code should work, but not that often how it should NOT work. And one may think that all this should be more than sorted out nowadays. But, for some reason, every now and then I keep landing on places were you are told to write your own unit tests (or maybe you´re not expected to write any at all) and have one of your peer developers review and validate your new functionality based on whatever functional knowledge you convey to them... which feels kind of dumb to me, as with that knowledge come your own biases. There is a saying which reads "buy cheap, buy twice". In software development, skimping on QA is no exception. How do you handle testing in resource-constrained projects? I'd love to hear your experiences. 

6

I've really really hated the term "Digital Transformation" for a very long time - so it is with some humour/curiosity/alarm that we were told by a client this week "OutcomePath has put us in control to Digitally transform our business, and put our destiny back in our own hands". As Ade says below - we also did it without partner agreements, licence fees or hidden agendas. I still don't like the term - but if it is what we do, and people like us for it, AND we can change peoples minds about what good consultancy and delivery is - then I suppose I should change my mind too. #DigitalTransformation #YesIEvenHashtaggedIt

15

Stop calling automated testing 'checking'. One of the things you will have heard as a QA engineer is that 'automated tests don’t test'. The idea behind this is a bit nebulous to me, to be honest, but clearly, it has to do with the assumption that no new information can be gained from running an automated test script. In this school of thought, we’re told that only active human intervention gains this new information. I’ve forever been baffled by this. Automated tests are created by humans, who (hopefully!) think about what risk they are covering, and why we need the information this test provides us with. Because knowing that your signup flow is functional isn’t more or less relevant whether a human checks it or a machine does.

114

73 Comments