Faster Testing, the Exploratory Way
Faster Testing, the Exploratory Way
As a tester, have you ever been called a bottle neck—the point in the development process where everything slows down? Let's take a look at some ways to break that bottle neck open.
Join the DZone community and get the full member experience.Join For Free
As a tester, have you ever been called a bottle neck—the point in the development process where everything slows down?
In the best cases, testers find problems that either slow down the release, add more work for the development staff, or both. At worst, testing is a cursory set of simple checks which doesn't shine any new light on the product. These situations don't just happen by themselves, we get into them by spending too much time on things that aren't testing.
Let's take a look at some ways to break that bottle neck open and explore more.
Waiting is one of the dirty secrets of software work. The front end can't work till the back end and API are all hooked up. The back end won't do anything until the database is designed and tables are in place. Even in fast moving agile environments, this means I usually won't have something to look at for a couple of days at least.
I joined an agile team that had already established ways of working, some of which were very traditional. The developers were working from highly detailed specifications and delivering features at the same time. By the time that a feature was in a build, the tester was expected to have some sort of documented test plan, and ideally a set of test ideas, documented. If I had something in my queue to work on before that feature was delivered, that new feature might sit for a day, so I might first write the required documentation.
Waiting to get the documentation started prior to looking at the new product was a mistake; I should have started right then and there. Test plans are emergent when using exploratory testing, because each new thing I learn guides where I must go next and helps me to decide what is important. Just because it isn't written down doesn't mean there is no plan or test ideas.
Explore With Tools
APIs and micro-service architectures, which allow developers to build functionality one piece at a time, are currently popular. The last company I worked with had an API for anything that touched data. If you wanted to list all cities in a sales region, create a new advertising campaign, or search for customers in a certain demographic, there was an API for it. Having this made it easier for the development team to add or update back end functionality without breaking the user interface. I was excited, because that meant I could do a significant amount of testing before the user interface even existed.
Using a tool like HTTPie or Postman, I was able to do most of the testing that directly involved data. If a new type of advertising campaign was being developed, I could discover what happened when I tried to create it without the required description field, which happened if I sent an end date that was in the past or in the wrong format, and what happened when the title was too long or had special characters. We regularly tested like that without having a finished product.
Of course, there is tooling for a lot more than API testing. I recommend trying out anything and everything free that you can get your hands on—firebug, chrome developer tools, fiddler, perlclip—you'll be surprised how tools can make your testing just a little more effective.
Pairing with a developer is one of my favorite ways to test software.
I like to get into the office early when it is quiet. A developer on the team I was working with also had this habit. We had a symbiotic relationship—each morning, he would work on something for a while and eventually ask, "Hey, do you have a second to look at this?" I made time, even if I was in the middle of something. He would step through the new change and describe what it did, I'd ask questions along the lines of "What happens if I...?" One question fed into the next. He knew things about the product that I didn't, which helped me to concoct new test ideas. Generally, we found a few problems and he was able to get them fixed before they ever saw a build system.
Exploratory testing is a lot of things—learning, making judgments and decisions, and simultaneously performing tests. While you might be able to get the job done in a traditional scripted way, adding a little exploration might just get you there faster.
Opinions expressed by DZone contributors are their own.