LoopQA

Having spent thousands of hours doing exploratory testing as a team, one mistake that occasionally arises is a tester thinking that exploratory testing means just bouncing around the app and calling it done. At LoopQA, we use the analogy of a fireman clearing a house to explain exploratory testing. Find the baby’s room first. Make sure you've thoroughly checked it before moving to the next room, and so on. Just because you're doing exploratory testing doesn’t mean you shouldn’t go deep. Happy testing out there! #softwaretesting #qa #exploratorytesting

This article is consistently one of our top performers. Lately, I've been thinking about giving it a new spin and diving deeper into some of the concepts it covers. For anyone working in UX/UI automation, seeing web pages as a series of grids with unique elements is incredibly beneficial. These unique elements can be referenced within parent elements for non-unique ones, which can make your automation tasks much more efficient. It might sound a bit tricky, but once you get the hang of it, you'll find it makes your work a lot easier. You'll encounter this almost daily in automation, so understanding this concept can really give you an edge. I'm considering expanding on this topic and would love to know if you think it would be helpful. Drop a comment if you're interested, or if you have any questions about it. Your feedback is always appreciated! In the meantime, feel free to check out the article if you haven't already. It's packed with useful insights and tips that I think you'll find valuable. Looking forward to your thoughts! #Automation #AutomationEngineer #Playwright

Oops, this one might be a bit last-minute...?? But we'd love for you to hang out with us at Playwright Happy tomorrow at 7AM EST! If you can't make it tomorrow, we'll be hosting a YouTube Playwright Happy Hour later this month! As always, thanks to Debbie O'Brien Max Schmitt Butch Mayhew Tally Barak & the other Playwright ambassadors for the support! #playwright #testautomation

Created this fascinating visualization using Star-History.com that showcases the growth of GitHub stars over time for three major players in the automation space: Playwright, Cypress, and Selenium. It's inspiring to see how the open-source community rallies around tools that push the envelope in software testing. From the looks of it, Playwright and Cypress are experiencing a meteoric rise, although Cypress may be softening slightly. Big shout out to Star History for making such insights accessible and easy to understand. It's data like this that helps us stay ahead of the curve in tech! Are you team Playwright, Cypress, or Selenium? What’s driving your choice? Let’s discuss below! ?? #TechTrends #OpenSource #Automation #SoftwareTesting #DevTools #Playwright #Cypress #Selenium #StarHistory #GitHub

When I ran operations for a startup, I read a ton about continuous delivery. The idea of a frictionless deployment sounded like the gold standard. It would be faster, cheaper, & lead to more stable releases. But it never happened. 5 years & a bunch of battle scars later, I've since come to believe that in order to achieve continuous delivery, you have to embrace a methodology like TDD/BDD. Simple enough? Right? Well it could be. But my understanding (I've only read about it extensively) is that transitioning into TDD, BDD or other similar philosophies is a fairly large lift. It involves re-thinking how you code, redefining roles, & process. But as far as I can tell, totally worth it! BUT... the reality I've come to see working with software companies is that there are a couple hurdles with TDD a large percent of organizations just can't get past. 1. Expensive developers writing tests being "worth the time". 2. Refactoring a legacy code base to add Unit Tests. 3. Redefining a culture where developers actually believe they should write tests. Some companies just aren't going to make the necessary changes. So if we agree that in order to achieve continuous delivery you have to embrace TDD/BDD etc & that a sizable number of companies just won't fully embrace these methodologies.... Can an organization remove friction in the deployment pipeline with automated testing? Is it worth it? Largely, my answer to most organizations is - "Absolutely, you can remove A TON of the friction & totally worth it". Particularly if the alternative is a 30 hour manual regression. Best you can implement this either with an internal QA team or third-party. But if you go this route, you have to understand their are two main limitations that need to be managed: 1. Because your developers aren't maintaining the test automation, any new feature they push will break some portion of the suite. This will slightly slow down getting feedback on the push. 2. An E2E suite is inherently a more complex code base to manage & will be a bit more flaky. Totally doable, but needs a plan. Taking the step is start building automation with a QA team or third party won't achieve frictionless, but you'll certainly make a HUGE step forward in getting feedback to your development team without having to fully embrace a methodology like TDD. This is a pseudo sponsored post as my company provides Test Automation. Want a faster feedback cycle for your dev team? DM me & we'll build you out a E2E suite with Playwright #testautomation #continuousdelivery #softwaretesting