I have been a professional software tester in various capacities since 2005. In my current role, I am a consulting software tester and writer working with Excelon Development. Outside of work, I am currently serving on the Association For Software Testing Board of Directors as VP of Education helping to facilitate and develop projects like BBST and WHOSE. I am also a student in the Miagi-Do school of software testing, and facilitate sessions for Weekend Testing Americas.
I am deeply interested in software testing and delivery, and also helping organizations fix problems in measurement and metrics programs.
Supposedly there is a constant tension between developers and testers, like the roles of artist and art critic. They can’t exist without each other, and yet they can’t get along. It doesn't have to be that way! Here are two ways testers can reduce that feeling so that developers and testers can work better together.
Some people think a good indication that a piece of work is done is if it's been tested. But by whom, and how? Testing alone doesn’t specifically determine whether you are done—especially when we probably don’t mean the same thing when we all talk about testing. Here are two ways to know when your work is truly done.
Testing can get complicated when each project is using a completely different toolset, language, and reporting status, with different measurements and formats. Testing is a reaction to context and what we encounter, so how we test cannot be standardized. What we can standardize is the stuff that surrounds the testing.
There's a simple rule for the minimum values testers should explore: “none, one, some”—or, how the software behaves if you send it nothing, one thing, or some set greater than one. It's not comprehensive, but it gives a good feel for how the feature works at the moment. Developers can also use this in unit testing.
Testing is an accessible career choice for people who don't come from the typical paths into a tech job. Previous jobs and formal education should matter less than the abilities to observe, identify risks, and report that information. How can we change our interview processes to highlight these skills and mindset?
There are lots of tool options out there for UI automation. Cypress is an interesting tool for browser automation because the architectural overhead is lower since there is no emphasis on page objects, and it encourages you to manage state by building tests as small as possible. Here's how it gives you concise tests.
Testers need to find important information about product quality and present it in a way that can be acted upon. As the people building the software, developers are in a great position to observe the product. By monitoring the test environment and conducting unit testing, they can help inform about product quality.