Creativity in Software Testing

Software testing illustration

What’s in a name? Well, in the case of Art+Logic, our name conveys the idea that software development is a combination of both art and logic. We find this to be the case in all aspects of the software development life cycle. And this is definitely true with software testing.

Some testing can and should be very logical in nature. For example, any repetitive testing should be included in test cases and considered for automated test scripts. These can be executed quickly and can efficiently cover a large portion of the application under test.

A main goal here is to detect bugs as soon as possible; definitely before an end user sees them, and preferably as close to their appearance as possible — possibly when integrated into a code pipeline deployment. Fixing a bug earlier rather than later saves time, cost, stress, reputation, and much more. But that’s another topic altogether.

Relatively few software projects can be adequately covered with just formal test cases or automated testing. The vast majority also require manual testing. Although writing test cases and automated test scripts surely requires creativity, manual testing has creativity at the root.

Manual testing requires careful and creative planning and coordination with business and technical objectives to be sure they are all covered. Once the testing starts, the tester must draw upon previous experience and intuition to make this testing as effective as possible. We might call this directed creativity.

At the least-restrictive end of the creativity scale is exploratory testing, which is an especially valuable type of manual testing that is often neglected. This unscripted testing should be a regular activity in the software development lifecycle, because it can take full advantage of the tester’s creativity and intuition. This is testing without borders.

Smoke testing by a project manager or other team member as a final step before any release can also be considered a type of exploratory testing. Smoke testing brings in another set of eyes after planned testing has been completed, covering as much of the application under test as possible in a reasonably short period of time in order to increase confidence in the release, much like smoke quickly spreads out to fill a room.

Smoke testing may include a general goal in the otherwise unscripted testing session, such as exercising relatively common functionality, or perhaps particularly risky functionality. The tester may be someone with extensive knowledge of the project’s business and technical objectives, or it may be someone who represents either a casual or trained end user.

Whatever the case may be, exploratory testing is a really good tool for approximating the random or spontaneous behaviors of end users. It can cover user behavior that hasn’t been predicted. That’s what makes it so valuable, especially when utilized together with the other more logical testing methods. Exploratory testing should be included in any test plan.

End users are quite creative in getting software to do what they want it to do. It surely follows that software testers should apply an ample dose of creativity in helping to prevent bugs from being released to end users.

It turns out that there’s quite a lot in a name.

QA & Requirements Gathering: Why?

Logo for QA

One of the most common misconceptions about software testing is that QA does not come into play until the development of a module is complete and ready to test.

In actuality, the earlier QA is involved in the Software Development Life Cycle (SDLC) the better. Studies have shown that up to two-thirds of defects can be attributed to requirements and design.


I’m Sorry: Your Software Project Will Never Be Finished.

Photo by Rene Böhmer on Unsplash

No, really.

In fact, when you go live, your software shouldn’t be “done.” If it is, you’ve done something wrong.

You see, in the history of software, there’s never been such a thing as a piece of software that launched without bugs. Think of your favorite, most used platforms. Gmail. Facebook. Salesforce. All are brimming with bugs. Every day a user writes into their contact forms about a bug they discovered, and while a lot of them are PEBKAC errors, a lot of them are legitimate bugs. And the ticket tracker logs them, someone triages them, and, eventually, most of them will be corrected.

But before that happens, some new feature will be added, or an existing feature will be modified (‘member when Facebook separated out the messages app from the FB mobile app?), and that will create a whole new series of bugs. (more…)