Anne-Marie Charrett

Here's the next Ministry Of Testing - Auckland meetup https://lnkd.in/gYVeKUZX where Francis Ho and the team at Auror will share their experience from the other side of the recruitment! Learn how to make your job applications stand out! Join us for an insightful session where we reveal the nuances of CV screening and technical interviews. Rather than just discussing generic tips, we will use real world demonstrations to show you what CV screening looks like from the hiring side, decode what technical interview questions really mean, and explain what hiring teams are looking for. Gain insider tips to enhance your job applications and interview techniques. Note - This session is geared towards those with some experience in software testing, as breaking into the industry or finding your first job after graduation requires a different approach.

13

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

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

An interesting article that popped on my LinkedIn feed this morning. My business unit just went through a salary revision exercise and so this one stopped my scrolling finger. According to this article, employees are comfortable with vertical inequality but dislike horizontal inequality in their paychecks. Finding out that their managers got paid more seemed to make employees work harder. But learning that their peers get paid more had a negative effect on their effort and performance Its advice to organizations? Keep salaries compressed among employees in the same position but offer them large raises when they get promoted to a higher position. The authors encourage companies to experiment with pay transparencies after figuring out what their employees want. My take from an employee point of view: I believe in what I call the "Golf model". Compete with yourself and compare against your 'last round' and what you want as your personal best for yourself. If you are close enough to your personal targets, focus on other things that matter for your next. Else, replan and take action. Don't let every new bit of information or rumor about the next person's salary decide if you should be happy today or how much effort you will put into your work that day. Play your own game, improve your own score, and ultimately, seek satisfaction in your own journey. What do you feel about pay transparencies?

26

11 Comments

Next year is starting to take shape. I’ve got two new talks I’m working on, and I’m thrilled to be giving one of them at NDC Melbourne at the end of April. I see a lot of discussion about serverless or containers. When actually many modern apps have use cases for both. In this talk I’ll dive into patterns for modern application architecture. Where to use containers, where you might want to reach for more reactive functions and how use both together with little to no infrastructure overhead. https://lnkd.in/ekQ7h5PF

46

1 Comment

After 11 years of running a software engineering company, particularly collaborating with clients who had their own engineering teams, I realized that clearly defining how you add value and how the client perceives that value is crucial—especially when that value drives the growth of both companies. In March 2013, we began working with an Australian client that had its own internal engineering team, which we needed to collaborate with. At the time, we were two years into our operations—young, Black, fresh university graduates given a big opportunity. Since then, we've worked with large telecom companies, banks, startups, and Fortune 100+ companies. At this stage of our business, doing things just for the sake of revenue without delivering clear value no longer works. For example, one way we add value is by being equally invested in the client's product because we see a commercially viable opportunity for both of us. Another example is helping to significantly reduce the client's overall capital expenditure. We've put together a list of strategies that can assist engineering teams from different firms. You can find the link in my first comment. Please feel free to share your experiences to help us or others in the community.

34

1 Comment

As the Australian Representative for Wolkk, I am proud to share how we excel in implementing Test-Driven Development (TDD) within our agile distributed teams. TDD is a critical practice in Agile software development that involves writing tests before the actual code. This approach not only ensures that the code is correct from the outset but also significantly enhances its reliability and efficiency, minimising the need for later debugging and revisions. At Wolkk, we've seen how TDD fits perfectly with the dynamics of distributed teams. It fosters a strong culture of collaboration and communication, essential traits for teams spread across different geographies. By focusing on tests first, our teams can quickly pinpoint and address discrepancies or issues in project requirements. This proactive identification of potential pitfalls is crucial for maintaining the pace and quality of development, leading to a smoother and more efficient process. Implementing TDD allows us to maintain a high standard of code quality and project alignment, which are vital for the success of complex software development projects. It helps our teams stay aligned with the project goals and customer expectations, ensuring that the final product is not only functional but also robust and user-centric. The benefits of TDD in our agile distributed teams have been remarkable. It has led to enhanced product quality, reduced time to market, and increased client satisfaction. Embracing TDD is just one of the ways Wolkk ensures that we deliver superior software solutions, irrespective of the physical distances between our teams. #TestDrivenDevelopment #AgileSoftwareDevelopment #Wolkk #TechInnovation

2

I am (still) looking for my next role. If you, publicly or quietly, are looking for a senior technical leader/executive hit me up for a chat. 𝙏𝙝𝙞𝙨 𝙞𝙨𝙣'𝙩 𝙖 '𝙬𝙤𝙚 𝙞𝙨 𝙢𝙚' 𝙥𝙤𝙨𝙩 Though everyone on the market at the moment knows how hard it is. Rather, this is an attempt to broaden my reach beyond the regular recruiters, headhunters, and others in my network that I regularly reach out to one-on-one. They've been awesome so far - you all know who you are and I thank you for the coffee, chats, support, advice, and leads you've been able to provide. It's just a struggle to keep coming second despite the best attention and effort, and I hope everyone has something similar to the support I've received. I'm looking for a new senior technology leadership (CTO, Head, VP, GM) opportunity where I can help teams across leadership, strategy, culture, growth, and ways of working. I'm also open to shorter term interim, contract, and advisory and coaching fractional roles where I can help. Throughout my career, I have demonstrated a consistent ability to lead and inspire high-performing teams, drive innovation and organisation wide agile methodologies at varying scale, deliver to outcomes, and align technology strategies with business goals. My sweet-spot for a permanent role seems to be scale-ups and mid-size companies:   • looking after groups of 30+ to 200+ people   • across leadership, practices, strategy, alignment and continuous improvement   • enabling teams to improve efficiencies in ways of working and delivery   • and aligning technology groups to the business strategy. I'm also keen to play an advisory/coaching role for individuals and startups, along the same dimensions. If you're in the same boat please comment or repost and we'll compound the message - hopefully helping each other out. Let me know if you hear of anything along these lines in the hidden market - DM me and I'll share my calendly link to hook up a call or a Sydney CBD coffee. Stay positive… #tinyleadership #jobhunt #jobsearch #jobseekers #leadership #cto #executive #factionalcto

165

6 Comments

💡 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

There’s been some really interesting chat about continuous deployment as a good way of enabling teams avoiding “release fatigue”. In my experience, here’s what’s super important to achieve this: 🧑‍💻 Reviews - In addition to the usual review process, I’d recommend a QA and dev ops resource reviewing pull requests to be essential. The advantages are obvious - extra pairs of eyes help spot issues but also help build familiarity with the product at a deep level. 📖 100% test coverage - If you are deploying every code change to production then you better be darn sure that sucker works, right? :) 🤖 Code Check Tools - using automated tools as part of the code submission process can help maintain standards and check for code smells. We have consistently found this to be very useful and though on occasion it causes the odd grumble (usually from me!), it’s really helped improve our code! 💻 Testing and Deployment Pipeline Automation - every pull request should successfully be tested at each stage (dev / test / stage / production) to ensure that there’s full confidence in any change. These pipelines should automatically roll back changes if they don’t pass muster. ⚖️ Small Pull Requests - ideally with a maximum of ten files changed, makes it easier and quicker to review. This is super important, and effort should be made to effectively split pull requests if they’re bigger than this! 🏎️ Configurable features - configure features to be turned on or off via config to avoid any roll backs for major feature activations. 🪵Logging - having good detailed logs at each stage is a really good way of ensuring that you can quickly and simply diagnose issues. Don’t overlook this! :) 😀Be Sensible and Kind - if you’re working together, giving positive and useful feedback in a kind manner is hugely helpful. It helps to foster a good team spirit, hugely essential! 🗣️ Communication - encourage cross team and cross function communication, this encourages full team work and allows any issues to be called out and resolved early. Also, I’ve found that copious amounts of dad jokes really help also, but that’s just me! Do you have any thoughts on the above? Anything you would do differently or items that I’ve missed?

8

2 Comments

Thanks to everyone that came to see my talk at ServerlessDays ANZ yesterday! Here are the slides. For those that missed it, here are the main lessons I shared: ✨ LLMs are not magic, they're just another useful tool in a builder's toolkit ✨If you want to be build with LLMs quickly and cheaply, see how far you can go with prompts and RAG. ✨If you need more control than you can achieve with those, you'll likely need to do fine-tuning, tuning or even training, all of which are much more expensive comparably. ✨Plan for your models to change all the time - use Artificial Analysis to navigate the changes ✨Plan for your prompts - version your prompts and construct them independently of inference ✨Getting LLMs to behave consistently for your use case is super challenging, but there are tools like the Seed and Temperature features to help ✨Hacking LLMs to behave outside the intended behaviour is easy, but you can architect around this using techniques like prompt proxies (thanks to Tomasz Tunguz for sharing great design patterns) If you have any questions about building using these tools, feel free to reach out!

31

3 Comments

🥂 🎉 2024 was a blast https://lnkd.in/g-F_YZth Looking ahead to 2025: A focus isn't just on integrating AI—it's on creating adaptive quality engineering approaches that recognise technology as a collaborative partner, not a replacement for human strategic thinking. The future belongs to teams who can navigate complexity, not just automate processes. #QualityEngineering #AIAssurance #DevOps #Observability

10

Google’s 2024 DORA State of DevOps was on my reading list this weekend but instead I decided to read Rachel Stephens’ writeup over on the RedMonk blog. The most interesting takeaway this year is that CoPilots have become established in the SDLC but we’re not seeing gains in productivity. The hypothesis is that coding is not a bottleneck to software delivery, so optimizing that has no gains and there may even be a drop in productivity due to more rework required. On a personal note - I’m only an occasional hacker but spent much of yesterday fixing and refactoring some Python for a data analysis project - I would be literally useless if it wasn’t for coding assistance. But I’m really not representative of the DORA report cohorts. As they stand, I think coding assistants are great for reducing the learning curve (new language, framework, etc.) but they are less useful with design and structure of code.   

1

There doesn't have to be a complex system managing dependencies. A few simple conversations can usually be a powerful starting point and move the needle . If you don't know what's changed - how can you understand the impact? If you can't understand the impact how can you prioritise your testing and quality strategy? You need visibility to know: - What was added? - What was removed? - What user scenarios might be affected? Without this clarity, you’re left guessing. Guessing leads to misaligned testing, wasted effort, and increased risk. So, before diving into automation or complex test strategies, Start with conversations. Get visibility. Understand change. Then build your quality strategy on a solid foundation. #Quality #QualityEngineering #OuterLoop #Impact #Traceability

12

My favourite here is Number 3 - (Not) Serving as an Umbrella for Your Team. My take: + For the best solution, and motivation, everyone needs to know why, not pull tickets. + Engineers need to meet stakeholders to they have an appreciation for the human side of things + Junior devs might say "all I want to do it code", but they best gift you can give them, personally and professionally, are soft skills, time/project management skills etc. + No one works in a bubble. Shits hits fans, and lessons are learnt about working on your main project *and* managing to lend a hand putting out someone else's fire. It should be done willingly, not as a credit for the day you'll need them to do it for you, which they will. https://lnkd.in/eKvrRyFh

Can be a rug-yank if incorrectly executed. Also there’s all sorts of other factors that affect the perceived success in the short term of a transformative leader - for example misinterpreting the success of long running internal initiatives… their success can be attributed to the new leader entering because the results took x months to manifest themselves. Ideally you see zero direct impact with the hire in the first quarter or two depending on company size

4

If you've built with low-latency data in the past, it may have come at the expense of weak consistency guarantees. But some real-life use cases require always-correct results: ❌ You don't want your auth service intermittently giving access to the wrong users. ❌ You don't want to shut down a user's credit card unless you're sure they're the target of an account takeover attack. ❌ And, you don't want to tell users a package has been delivered when it's still on its way. The ✨ good news ✨ is that there are stronger consistency models that we can layer over streaming systems. If you're trying to build real-time applications that need always-correct data, check out my talk at Current this September: "Consistency and Streaming: Why You Care Should About It." For more details, see: https://lnkd.in/gvBMRHSW

24

I'm a fan of a good mnemonic and I'm liking the simplisticy of this example is explaining the trade offs when considering automation test characteristics https://lnkd.in/gfrutx8N

5

1 Comment