Software Testers’ Greatest Fears on Halloween

As Halloween approaches, everyone is searching for the scariest costume to outdo their peers at parties and work events. But software testers aren’t haunted by typical ghosts, witches, and vampires. So, what are software testers’ greatest fears? What really frightens them are the factors that hold up development and delivery cycles.

If you want to really want to scare your testing team this year, try channeling one of these situations that make testers want to run and hide.

• Bad responsive design – Responsive design is paramount to any decent web applications —  just because a website is functional on a mobile device doesn’t mean it’s pleasant to look at and easy to use. Developers are tasked with creating a cross-compatible website, while testers have to go through on multiple browsers, devices, and operating systems to make sure that a website that’s designed to be responsive is actually user-friendly. You can add all the media queries you want, but if an application looks better on a desktop than it does on a mobile device, it’s back to development.
• Manually running repeated tests – Though you want a great design, it’s not going to do you much good to just test visual components. While skipping functional testing could lead to testing horrors, performing regression tests when code changes will help ensure users don’t run into any issues that scare them away from your web page. Of course, conducting these tests by hand over and over is painful for any tester. Instead, using a Record & Replay tool or an open source tool like Selenium for script writing paired with an automated testing tool like CrossBrowserTesting means that repeating tests doesn’t have to be so horrifying.
• Flaky builds– When your automation build is flaky, it loses its effectiveness. We hear it over and over again, but it’s true. What’s more terrifying than wasting valuable time writing scripts that don’t work or give false positives? Flakiness can derive from a lot of different factors, but until you figure out the source of the issue, your build is going to be haunted by unstable automation. Check out our article for more ways to prevent and fix flaky tests.
• Bad reporting – While working as a lone tester isn’t always ideal, having a testing team that doesn’t organize reporting and documentation just makes for chaos. However, with integrations like browser screenshots, visual reporting, and Slack created for that exact reason in CrossBrowserTesting, there’s no excuse to skip this crucial step. Keeping tabs on testing helps everyone — from management and developers to testing and operations — stay on the same page and understand what needs to be fixed or changed.
• Being blamed for bugs – The reason the term “Quality Assurance” can be such a sore subject is that testers know that there is no way to actually assure quality. That’s because applications have endless areas that could be tested and not nearly enough time to test them all. The job of a QA team is often attributed to catching mistakes, but we shouldn’t be so worried about making mistakes in testing that our efforts become ineffective. The solution for this problem often lies at the hands of other stakeholders in the software development lifecycle who need to better understand the testers’ job and open channels of communication to build a more efficient development and testing strategy.
• Selenium struggles – Testers may not be afraid of a challenge, but Selenium is a tool that has a lot of uncharted territories. Learning test automation in the first place takes a good amount of time to master. Even once you get your bearings with learning a coding language and getting comfortable with Selenium testing, complications can pop up and interrupt your script writing. Dynamic web pages, alerts, multiple tabs, and validation can all be problematic if you haven’t learned how to handle them, which is why we have a guide for common Selenium challenges. Alternatively, to keep testers on their toes, check out our tips on how to write a bad Selenium test.
• Internet Explorer – Cross-browser testing is scary on its own, but the most frightening thing any tester can come in contact with is Internet Explorer. It seems no matter how great a web page looks on Chrome, Safari, and Firefox, Internet Explorer will always be an outlier during your screenshot comparison tests. Unfortunately, other than continuing to run manual and automated tests in IE, there’s no way to avoid this nightmare since (for some reason) it still holds a percentage of browser market share.

While (most of) these worst practices have not proven fatal, they can be detrimental to Agile and DevOps teams that focus on committing more integrations, continuously testing, and delivering quality software quicker. At the end of the day, nothing is scarier to software testers than being in a position that prevents them from doing their jobs.

While you may want to spook your QA team with these ideas as October 31 rolls around, it’s best to be wary of them the rest of the year in order to create a tester-friendly workplace.