Phil Barker

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

The value of feedback loop on Postman collections over the years can't be understated - it just isn't visible and well understood. I mentioned the importance of this in my writing today on editors Dave Shanley and Florian Martens - I get a regular stream of these. https://lnkd.in/ecjSxZZe

13

Does anyone else in the software development industry, particularly testers, BA's and devs, find it frustrating when you try to fill out a web form online and it is unusable, then you decide to let the person or org whose site it is, know, so they don't miss out on communications they clearly built the form in order to receive.... Then after screenshotting and documenting rnough info that their dev team will be able to locate, reproduce and fix the pronlem, suddenly you realise you were doing "me time stuff" but it kinda feels like you were just at work...? Lol... Worse actually, because at work, someone is interested in hearing what you saw and documented. Whereas chances are my email about the impossible to fill out phone number field I just encountered, will probably disappear into a black hole known as "customerservice@..." I just tried to fill out a form, where my phone number was a required field. I tried numerous formats for my phone number, none of which were accepted. Including +6420.... 6420... 020..... 02 .... (020).... And then I even tried a landline number in case for some unknown reason they had decided to only accept landlines (that most of us don't even have any more, lol) and had not put any tips on the form to inform the user of this... various versions of the format of an 03.... number were also rejected. The form was wanting people located in Christchurch NZ to respond in case you are thinking it was rejecting my NZ number because I am not in the US... I dutifully took screenshots and sent the url and a brief email explaining the issue to the contact email for the website. Anyone else ever have this and like to join my vent? 🤣 😂 (No, LI, I don't want to rewrite my vent with AI, though then it might have a (fictional) happy ending 😁)

1

2 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

Leveling Up: The Challenges and Wins of a Full Stack Upgrade ⚙️ After years of running stable on PHP 7.4 and Laravel 6, I finally bit the bullet and brought the backend of my SaaS app up to date. A few weeks of focused work later, it’s now running on PHP 8.3 and Laravel 11 (yes, that’s four versions of PHP and five version of Laravel in one go!). This upgrade journey wasn’t just about following the latest tech trends—it was about future-proofing and addressing the technical debt I’d accumulated over the years. One of the biggest challenges was with Laravel Spark, which I originally used to handle subscriptions back when I had zero experience in ecommerce. Unfortunately, Spark didn’t offer an easy upgrade path to Laravel 11, so I had to dive into the code and manually update it, all while fixing my old “creative” customizations. 😅 The frontend also needed some serious attention. What started as a Vue 2 SPA using Vuex and Vue Router has been upgraded to Vue 3. I hit a major roadblock when I realized Spark had embedded inline templates, which Vue 3 no longer supports. The solution? Migrating all the template code into single-file components, and along the way refactoring the Blade template logic to work seamlessly with the new frontend setup. This upgrade has been a challenging but rewarding experience. It’s a great reminder that pushing through the difficulties of upgrading legacy code pays off in scalability, security, and long-term growth.

18

BDD unlocks so much goodness You discover ideas you should throw away earlier You have testable specs that transform coding from exploration to implementation. You can easily decompose work to the point where you know things will take a day to complete. It’s the first skill I had to learn to unlock CI.

35

𝗘𝗻𝘀𝘂𝗿𝗶𝗻𝗴 𝗦𝗺𝗼𝗼𝘁𝗵 𝗝𝗮𝘃𝗮𝗦𝗰𝗿𝗶𝗽𝘁 𝗘𝘅𝗲𝗰𝘂𝘁𝗶𝗼𝗻 – 𝗔 𝗗𝗲𝘃𝗲𝗹𝗼𝗽𝗲𝗿'𝘀 𝗚𝘂𝗶𝗱𝗲 JavaScript execution can be a tricky business, especially when it fires off before a page is fully loaded. Ever seen a website with broken sliders, non-functional buttons, or elements that just won’t load properly? That’s JavaScript trying to run before the HTML and other resources are fully ready. This is a common issue that can impact user experience, leading to: ❌ Broken functionality (think sliders or interactive carousels that won’t work) ❌ DOM errors when trying to access elements that aren’t there yet ❌ Inconsistent behavior across different browsers due to varying load times ❌ Poor user experience due to incomplete interactions ✨ 𝗧𝗵𝗲 𝗦𝗼𝗹𝘂𝘁𝗶𝗼𝗻: Our goal was simple — ensure JavaScript runs after the page has completely loaded. Here’s how we made it happen: ✅ Wrapped JS code inside DOMContentLoaded or window.onload listeners. ✅ Used setTimeout() to strategically delay certain scripts. ✅ Implemented debounce functions to prevent multiple triggers and optimize performance. These methods ensured that JavaScript is executed only when all elements are fully loaded, preventing premature execution and boosting performance. 🚀 📊 𝗧𝗵𝗲 𝗥𝗲𝘀𝘂𝗹𝘁? With these tweaks, we’ve seen a noticeable improvement in our site functionality, reduced errors, and a more consistent experience across all devices and browsers. 💡 𝗖𝗼𝗻𝗰𝗹𝘂𝘀𝗶𝗼𝗻:  This approach is a must-follow best practice for all developers on our team to ensure reliable, smooth-running scripts and a top-notch user experience every time! 💯 #WebDevelopment #JavaScript #BestPractices #PerformanceOptimization #CodingTips #EncircleTechnologies #JSExecution #WebPerformance

13

How important is domain/industry knowledge within QA? Lots of companies see it as a big bonus when they’re hiring, with some even having it as mandatory - but do they really need it? Or are they just assuming it’ll bring them more value + less time spent on mentoring and getting someone up to scratch in those specific areas. There’s certain industries that I can see the argument for, whether that’s a specific financial platform, or companies that have to adhere to specific regulations (as an example) - but does the new ideas and skills that someone can bring in from a completely different industry, potentially outweigh that? Also, are these skills that difficult that no one pick them up - everyone has to start somewhere, right? Like anything, there’s pros/cons and this is just a generic overview - but being narrow minded and not considering an ‘outsiders view’ maybe isn’t always the best option.

27

9 Comments

TDD is expensive Like many other niche technologies Delivery of software is not only a technical problem It’s logistical and people problem as well It can be using Kotlin in Java company It can be adding a better database engine It can be applying Event sourcing to all systems You can say all of those are great But there are a couple of non-technical problems 🧠 Knowledge The whole team must know the new solution They need space to learn and practice You may get training from an expert Both cost money and time 🚦 Risk You face the bus factor What if the devs will leave? (they will) How will you maintain the niche solution? How much will it cost to hire or train a replacement? 👩 Hiring Adding new technologies narrows the pool of hires The more niche you go the harder is to find a good fit The longer hiring process will strain delivery You'll have to balance with higher salaries ☯️ Alignment What about your current team? 80% of them like tests but aren’t fans of TDD What will you do? Force them to learn or let them go? The culture will take a hit and retention will sink What can you do instead? Keep it simple Keep it boring Focus on the basics Drive incremental improvement Find alignment before picking new tech Get excited about the features and business If you don’t need to fix niche problems You get more time to deliver value

24

13 Comments

Over the last couple of weeks I've had people asking me if there is going to be another DDD (DeveloperDay) or DDDNorth - the short answer is yes! Sorting out venues, locations, dates, all whilst still dealing with what life throws at us has meant that things have slowed. But be assured, discussions are happening, plans are afoot, and we will let you know as things have firmed up! #DDD #DDDNorth #DeveloperDeveloperDeveloper #Community #TechCommunity

31

1 Comment

There are some software developers who join my course and it becomes immediately apparent that they won't be around for long. I see it very clearly. They put in the work, commit to the process and become relentless. You DON'T have to be the best developer to get the job. You have to have the right attitude. Why don't you make 2025 the year you land your dream job in tech? Ready? DM me for details of my VIP course #developer #jobs #careersadvice

96

10 Comments

I can’t tell you how many times I’ve been asked; "Why don’t developers just test their own work? Why do I need to pay for a tester?" Taking the time to understand the value of the people who test and approve your works, is an important part of engaging with an agency. Undertaking this step will help you to not only see why testers are such an integral part of software development, but how they'll help you to maintain a stronger relationship with your agency. 1. Regression Testing If you don’t know what regression testing is, this is super important to understand. When you ask your agency to develop a new feature for your site, you want to be sure they’re undertaking regression testing. Essentially, this is the process of testing (end to end) the elements around your new functionality, to confirm that existing site capability is maintained. There’s no point adding new features to your site if you’re breaking existing ones; hence the value of your test team. 2. Manual Testing Manual testing is a test method often used when introducing small or isolated updates to your site. This process involves interacting with the feature just like one of your customers, and ensuring the functionality produced by your developers meets specification. Manual testing, unlike automated testing, is a great way to test standalone features and ensure they do what they’re supposed to. If not, well you guessed it, the job will be sent back to the developer to amend with notes on where the item has failed to pass testing criteria. 3. Automated Testing When it comes to testing highly important use-cases, your test team may opt to write automated test scripts. This may include simulating items such as adding to cart, making a purchase or new customer registrations; and are often run when major site upgrades are implemented to be 100% sure everything's working as intended. Automated testing, although time consuming to setup, can save tens of thousands of dollars across high traffic sites when something does go wrong..all thanks to your friends the testers. 4. "Can’t developers just do this” Like most things in I.T, testing is a very niche skill set. That’s not to say that developers don’t check the work they’re doing and pride themselves on getting it right first time, but the process of having a qualified test engineer sign off a piece of work is an invaluable part of the delivery workflow you can’t do without. When it comes to saving in money in I.T delivery, after you’ve been around this world a while, you’ll soon come to realise shortcuts aren’t the way to do it. Choosing to focus on quality delivery and product smarts, will always deliver greater results than saving a few dollars here or there. So, remember, if you’ve learnt anything today, it’s to love and appreciate your testers! Often under appreciated, however not so strangely; always a major part of any successful eCommerce business! #testing #eCommerce #retail #adobeCommerce #shopify #bigCommerce

21

1 Comment

Your projects are not delivered by the number of resources listed on a spreadsheet… ✅ They are delivered by people... Some still believe that if a project has the right number of developers, everything will be fine… They can happily swap one developer for another… Or better yet, swap out several developers... ❌ With no impact… It doesn’t work like that… Developers are not just code-generating machines, they are people… On your project, they: 👉 Learned about the domain. 👉 Built relationships with the team. 👉 Visualised how your project could be built. 👉 Asked questions and gathered knowledge. 👉 Made the best decisions based on prior conversations. 👉 Gained an understanding of why things are done the way they are. It takes time and effort for new developers to get up to speed with an inflight project… 🧑🏻‍💻 When you swap out developers on a project, your timelines will take a hit… 👩‍💻

9

2 Comments

I feel a bit bad about IT businesses... there's a tendency to carry bad code that is hard to maintain. Now there's a surge of AI tools that are good at copy/pasting code but VERY bad at reducing repeating code and refactoring code structures, which can quickly lead to something that barely works but is impossible to maintain. There's also been a culture lately of rushing from one deliverable to the next, sprint after sprint, without too much care about code structure and long-term maintainability. Add to that firing 100K employees. I'm not sure I even want to touch that code-base that's going to get worse and worse in many companies.

2

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

#backtokotlin #androiddev | I've just had a rather productive morning today. I was able to catch up on some of the work for my temp QA job while also dealing with my own recovery, which is still slightly inconvenient at the moment. But I'll work through it. I always do. And then I wanted to spend the 2nd part of my Saturday resuming my Android/Kotlin development refresher. It has been a couple of years since my last active mobile app development. But this feels almost like riding a bike. The more I do, the more familiar it all becomes once again. It is while revisiting Kotlin and Android development that reminded me of how much joy mobile app development used to give me. I mean, sure I can also do the whole full-stacked web API shit. But this is the front-end development aspect that I am referring to. What really excites me about my new job as a front-end developer is that I won't just get to work with Android development, but I will also get to do Swift-related development for the iOS platform. I love this feeling of being able to rediscover the joy it gives me. Can you imagine? I've been doing Android/iOS development since 2012...2013. Wow, that's almost 12 years already. Are you also a mobile app developer or a front-end developer working on a mobile app? What excites you the most about your work? What brings you the most satisfaction? Share with me in the comments. #mobileapps #mobileappdev #recap #refresher #newjob #frontenddevelopers #frontenddevelopment #iOS #android #iosdevelopers #androiddevelopers #swiftprogramming #kotlin #joy #rediscovery

1