Explore the System: 99 Ways Workshop #50

The Software Testing Club recently put out an eBook called "99 Things You Can Do to Become a Better Tester". Some of them are really general and vague. Some of them are remarkably specific.

My goal for the next few weeks is to take the "99 Things" book and see if I can put my own personal spin on each of them, and make a personal workshop out of each of the suggestions. 

This entry marks the half way point in this experiment, It's been very instructive thus far, a real eye opener. Yes, there are many thing that I currently do, and there are many areas where I do very little. My experiment thus far has shown me that, indeed, I could have taken the statements at face value and said "oh yeah, I'm doing that already" and not realized just how much I could be doing to be more effective. Today's entry is a perfect example of this.

Suggestion #50: Explore the system!! - Vishu Udayan

This is a seemingly basic yet deceptive statement. Even simple applications have aspects that we are not aware of, until we take the time to dig in and really see what is going on. What may seem to be a simple web site may have a framework with a number of dependencies, and updating one of them can require others to be updated in the background, with us being none the wiser… until we notice something is no longer working the same way, and we cannot really explain why.

Almost all applications now have code, libraries, and various moving parts that go way deeper than we realize. If we take the time to really start looking into all of the pieces that make up the application, we will find not just what makes the application tick, but ways we can leverage that information to further our testing strategy.

Workshop #50: Consider the system that contains your application. Describe and define it with as much details as you can. Describe the architecture, the machines needed, the end points, the middle components, the database, the front end, anything that can give you an idea of the relationships in the system.

As a kid, I used to enjoy drawing various things. Space ships, animals, trees, etc. The hallmark of most of my drawings, though, were that they were fairly simple. There's a reason that my drawing skills are not something I'm known for. My daughter, on the other hand, has tremendous talent in drawing. The reason? She's gone way beyond the basic surface level aspects, and has actually delved into techniques that allow her to make more predictable and more elaborate drawings. She's looked at aspects of what goes on in the structures of items like people, trees, and objects, and in the process, can draw very realistically.

When we look at the systems we are working with, we are at a disadvantage if we only focus on the front end of an application. We will find that there's a lot that we miss if we don't understand all of the moving parts in, say, a Rails framework (if our application is built upon Rails). We can miss important clues if we don't understand all of the relationships in our database. Taking the time to look at all of the elements and actually take notes as to where things connect and interact can open up considerable avenues for exploration and discovery.

Consider the application you are working on today:

What does it entail?
Does it have a front end layer that is presented to a user?
What makes up that front end?
Is it a traditional compiled app that runs on a traditional computer?
Is it a mobile application?
What elements do you as a user interact with?
Do you interact with both a traditional front end and a mobile front end?
How do they differ?
What parts do you see in the computer/web version that you don't see in the mobile version?
Why?

Think about the infrastructure that's needed to give you the experience your application provides:

Is it self contained?
Is it a web application?
If so, how many servers and services do you need to be running to provide the experience the user sees?
What generates the front end?
What libraries are used to make for the interactive components?
Which JavaScript libraries and frameworks are being used?
How much do you understand those frameworks?
How is your data stored?
Do you know which database system is being used?
If you wanted to check on the structure of the database, how would you find out what's available to you?
If you needed to perform an ad-hoc query on the database, could you?
Are there additional services that you need to be aware of?
Does your system use caching?
Do you have a special search component?
What ports do these additional services run on?

Once you have determined all of these moving parts:

How would you represent them?
Could you explain to another tester all of the moving parts of the application?


Here is where, to borrow from my daughter's experience and example, taking the time to draw and delve a bit deeper into the systems, and make some maps, can be extremely helpful. These maps can be a simple as diagrams on pieces of paper to fully documented topologies and relationship drawings online. Standalone sections could reference higher level documents that show additional connections and interactions, with each node having more and more detail as the tester looks closer. Much of this work may already be done within the architecture documents by the development team, but don't assume that every step of the way has been documented in this manner.

Bottom Line:

Systems are complex, and they grow and adapt as needs change and systems mature. Left to their own devices, it can get to a point where the left hand really doesn't know what the right hand is doing. Some people may know a lot about the systems, but it's a safe bet that very few organizations exist where everyone knows how every moving part interacts. 

I can safely say that, in my current environment, there is a great deal about our infrastructure and code base and how it interacts that I do not know at this stage. By taking the time to diagram and step through all of the moving parts, I will discover more mechanisms, and those mechanisms will warrant questions. Those questions ail help to guide me in further exploration and discover of the applications that we use, and what their dependencies might be. And so on, and so on, and so on. The plus side is that it's a great way to get further understanding of the applications we work on. The minus side is that we really have no idea how deep the rabbit hole goes. Only one way to find out, of course ;).