My last couple of blog posts on the subject of innovation tools have gotten pretty wordy. I’m going to try and keep this one a little shorter.
My definition of abstraction, for the purposes of this article, is that it’s a process of removal. To abstract something is to consider a thing independently of its associations or attributes.
A picture used to be a sum of additions. In my case a picture is a sum of destructions. – Picasso
In 1945 Picasso created his famous series of Bull paintings, in which he gradually eliminates features and attributes through a progressive analysis in order to arrive at the essence.
The picture below caught my attention earlier in the week:
Apple have clearly (and famously) taken on board this lesson. Google also, though arguably to a lesser extent. But how can I apply this kind of reductionist thinking, in my day job and elsewhere?
Well, I figure there’s a lot to learn from the process that Picasso seems to have followed. Were I to consider the process as an exercise in exploratory testing for example:
|Painting||Picasso's refinement||My testing refinement
|Picasso starts with a realistic brush drawing of the bull.||I might start off with an initial impression of the system under test. A complete picture of the system as I understand it at a point in time.
|Picasso goes on to bulk up his picture of the bull, focusing particularly on the the coat and head.||As I explore the system I become more aware of the user interface (the external interface or coat) and may choose to focus on a particular area - a page or function for example.
|Picasso begins to experiment with lines of force in his third image, examining the muscles and skeleton.||I consider muscles and skin to be analogous to the logical and physical architecture of the system under test. Logically there may be a separation between presentation, business logic and data tiers for example, but in reality there could be any number of servers (physical or virtual) on which the system resides. During the course of my exploration I may begin to consider what the architecture looks like and what impact this has upon its behaviour.
|In plate 4 Picasso refines his abstraction by focusing on the main anatomical aspects of the bull.||Following on from the step above, I can do the same as Picasso by considering further what architectural aspects of the system I’m testing are likely to have an impact by narrowing my testing focus. Am I interested in performance, security or usability for example? If I’m interested in performance, then I might start to think about things like load balancing and how many application servers there are.
|In plate 5 Picasso starts to reorganise the dynamics of the bull according to his own artistic sensibilities. ||My analogy is beginning to break down a bit - but in my mind it’s a question of continuing my exploration and drilling down into the areas on which I which I want to focus. Carrying on with performance testing as an example, and bearing in mind load balancing is a typical bottleneck - I might decide to script and perform a simple test (assuming appropriate monitoring etc is in place) to identify whether or not the load balancer has been tuned correctly.
|In plate 6 Picasso continues to refine and adjust his study of the bull.||And so on and so forth. As my exploration continues, I design and perform tests to increase my understanding of the system, it’s architecture and design, seeking continually to confirm or refute my hypothesis about how the system might behave in various circumstances. The results of my investigation are reported to people who care using whatever mechanism seems most appropriate. (I’ve never had to use a lithograph, thankfully.)
|Picasso continues his study, ultimately refining the bull to a simple line drawing. ||Following the performance analogy still further - you could argue that in many cases this is exactly what I’m seeking to do with my performance tests. Reduce the behaviour of the system under load to a simple line, scatter or bar chart that can be used to communicate risks to the development team.
If you’re interested in a more complete treatment of Picasso’s study – you can find it here. All of the pictures are from the same site also.
I think a lot of what testers do boils down to a very similar process to the above. We take complex behaviours and carry out a series of tests, asking questions of the system to confirm or refute whether or not our model (painting) is correct. Having done so, we communicate the results in a way that is valuable and meaningful to people who care.
As I mentioned above, in some instances this report might be a line or scatter chart. In some circumstances it might be a whiteboard picture or architectural diagram. In still others it might be a mind map or a Post-it note. Sometimes it might be a formal bug report in some kind of tracking system.
The point is that our findings are communicated in a way that makes sense, given the context in which we’re working. Not doing so will almost certainly be construed as a failure to communicate effectively.
There’s other ways in which this kind of abstraction can be applied. When I think about my role on projects more generally for example, I like to reduce and simplify it as much as possible so as to retain an appropriate focus, when all around me are losing theirs, as it were. For me, this often boils down to:
- Finding and helping to solve problems
- Improving people and processes
The continuing trend towards leaner, more agile ways of working means that I’m always on the lookout for ways of simplifying how I work as well. Eliminating [unnecessary] complexity from tools and approaches wherever I can. I’ll talk about this some more another time though.
I hope you enjoyed this post. If you’ve got any further thoughts, I’d love to hear from you in the comments section below.