Quickly testing complex systems.

I’ve been hacking away at a test matrix for a relatively complex web system. The first plan was to build a series of detailed walkthroughs, ensuring that the full run of tests would hit every feature, button, tab, text box, and integration point. I started on the application’s front page by looking at all the buttons and options there, using screenshots to detail and describe what I was doing, and laying out all the possible routes. After a couple days of banging my head into that, I realized the size of the project I was taking on.

I’ve been hacking away at a test matrix for a relatively complex web system. The first plan was to build a series of detailed walkthroughs, ensuring that the full run of tests would hit every feature, button, tab, text box, and integration point. I started on the application’s front page by looking at all the buttons and options there, using screenshots to detail and describe what I was doing, and laying out all the possible routes. After a couple days of banging my head into that, I realized the size of the project I was taking on.

Problem: the matrix I was planning would be fantastic for some situations, but likely not for the ones I meet. That particular matrix would truly shine if I had the luxury of writing out a detailed plan for a team of junior testers, especially ones unfamiliar with the product. Unfortunately, I’m required to single-handedly run quick test sweeps of complex systems. I have to ensure that certain features work, and lower risk. I do not have the time or resources to do anything in any real depth. So why spend a month pounding out a textbook sized matrix for a system that I’ll never have time to execute? To make matter’s worse, the finished product would need to be quickly editable, because it’s a live system with frequent updates that affect how the end-users will use and interact with it.

New plan: I’m going to start by brain storming use cases. I’m going to write them out without much detail. A basic matrix will ensure that all critical features are hit, and that’s the backbone. From there, the use cases will allow me to aggressively leap into exploratory testing, hitting as much of the software as I can and documenting as I go. It’s the most flexible way to approach a big problem, and around here, with limited resources, flexible is king. We’ll see how round two goes.

 

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: