Start From The Past

After being in the computing business now for more than half a century, one thing worries me more than almost anything else: our lack of a sense of history. (Jerry Weinberg)

For a while now I’ve had a rule of thumb, heuristic, that I’ve followed when I’ve wanted to learn something new. I don’t actually remember if I learned it from somewhere or came up with it myself. Nevertheless, it’s been useful for me and I would like to share it with you.

Find Out Where It All Started From

If I want to learn something new, I will focus on the past and try to figure out where it all started from. This way I will lower the risk of being affected by Law of Raspberry Jam.

As for now, I think it’s most helpful if I share couple examples.

Case 1: Scrum

I wanted to know more about Scrum couple months ago. Considering the popularity of Scrum, its Wikipedia article is quite thorough. What’s most important, it has History section in it. Let me copy-paste the beginning of that section:

Scrum was first defined as “a flexible, holistic product development strategy where a development team works as a unit to reach a common goal” as opposed to a “traditional, sequential approach” in 1986 by Hirotaka Takeuchi and Ikujiro Nonaka in the “New New Product Development Game”.^[1] Takeuchi and Nonaka later argued in “The Knowledge Creating Company”^[2] that it is a form of “organizational knowledge creation, […] especially good at bringing about innovation continuously, incrementally and spirally”.

After learning that, I went and read the paper. What’s interesting, paper didn’t mention e.g. sprints, daily stand-ups or backlog. It focused more on identifying characteristics. Characteristics that leading companies showed (in 1986). Later, while learning about origins of Scrum, I ended up watching James Coplien’s talk at Youtube: Patterns: The New Defacto Scrum Standard. I’ve seen it several times since then. Perhaps the thing that strike me the most, was that James said how Scrum had been affected by Toyota Production System (a.k.a. Lean).

Learning about the work of James Coplien also led me to Scrum Pattern Community & their published patterns. Based on all the previous, my current understanding is that Scrum is about identified patterns & in the end: Kaizen. Successful teams have had patterns that has been part of their success. Those have been identified and came part of Scrum. It also reminds me that every team has its own context that they operate on. This needs to be considered when trying to apply a pattern (e.g. daily stand-up) to yours.

Case 2: Agile

I’ve also activated with Agile lately (this year). Sure, I’ve been familiar with Agile Manifesto & its principles. That’s though quite simplistic & therefore it makes you wonder how to interpret it. That’s why I wanted to understand what people behind the Manifesto thought about it, when it was published. I found one good article about it where Martin Fowler & Jim Highsmith explained their thinking behind every point & principles. Good to notice how the article is from year 2001, when the Manifesto was published.

There’s a lot more, if you have time, energy & curiosity. Martin Fowler has an interesting article on his website from July, 2000, where he describes the New Methodology. Then there’s also an updated version of the same article from year 2005. I haven’t yet read those. But that’s where I will go next. These are the people who were behind Agile Manifesto, they are the ones whose thinking I want to listen, when learning about Agile.

I would be naive though, if I would assume that agile software development came to life 13 years ago (2001). There’s one great article that reminds us how people were doing things smartly already in mid-1950s. Here’s one quotation (by Jerry Weinberg) from that article (Iterative and Incremental Development: A Brief History):

We were doing incremental development as early

as 1957, in Los Angeles, under the direction of

Bernie Dimsdale [at IBM’s Service Bureau

Corporation]. He was a colleague of John von

Neumann, so perhaps he learned it there, or

assumed it as totally natural. I do remember Herb

Jacobs (primarily, though we all participated)

developing a large simulation for Motorola, where

the technique used was, as far as I can tell, indis-

tinguishable from XP.​​

​​​​

When much of the same team was reassembled

in Washington, DC in 1958 to develop Project

Mercury, we had our own machine and the new

Share Operating System, whose symbolic modifi-

cation and assembly allowed us to build the system

incrementally, which we did, with great success.

Project Mercury was the seed bed out of which

grew the IBM Federal Systems Division. Thus, that

division started with a history and tradition of

incremental development.

 ​

All of us, as far as I can remember, thought

waterfalling of a huge project was rather stupid,

or at least ignorant of the realities… I think what

the waterfall description did for us was make

us realize that we were doing something else,

something unnamed except for “software devel-

opment.”

 ​

Case 3: Testing

 ​

On December, 2013,  I wrote a blog post about history of software testing and especially how first software testing teams were formed. It’s a good description of how testers were starting to came into software development 50 years ago. Because they concluded that it would help if there were people who were focusing more on testing than others.

​

It’s good to note though that I’m talking about software testing. Testing, the mental activity of questioning in order to evaluate – that goes far back. I haven’t put that much effort on tracking the history of that yet.

 ​

While exploring the history of software testing I ran into different kinds of papers. One particular (Evaluation of the Functional Testing of Control Programs from 1967) hinted where the demand for excessively structured testing came from.

 ​

Other way to learn about the history is to ask from people who remember far enough. I asked for example from Jerry Weinberg about origin of test cases.

 ​

This is a good reminder of the context behind birth of test cases. While it may be beneficial to use them in your context 60 years later, do note that access to machines is not that abominable these days anymore. If that’s the case, other reasons for using them need to be considered. This same thinking should apply to anything that you’re leaning into & haven’t invented by yourself.

​​​

Try It Yourself

 ​

Next time you want to learn about something new (e.g. BDD, Specification by Example, Exploratory Testing, Lean, Unit Tests), start from its history. If there are few people who are behind it, try to find what they have to say about it. Or perhaps you can even ask from them via email, Twitter or some other way. This way you’re increasing your chances of understanding the subject the same way as the people who came up with it.

 ​

Good luck!

 ​

To show that I’m not alone, I’d like to end this to Martin Fowler’s words:

 ​

In order to understand something, I often find it useful to know how it came about.

 ​

Advertisement

Testing Quadrants As A Communication Tool

 

 

Here’s a modification of Agile Testing Quadrants by Lisa Crispin & Janet Gregory (originally by Brian Marick). I’ve used this as a communication tool in our current project. As it might raise few eyebrows, let me explain couple things.

(Also want to mention that I’ve modified the Quadrants a bit from how they are actually on the project – i.e. what we are focusing on & what we are not focusing on)

Context & Background

I explained very briefly my current context on my previous blog post: Striving For Early Feedback

Besides that, I’ve had challenges with explaining what we (our test team of 2) is testing, with respect to all others on the overall system. Then I was listening Paul Gerrard’s talk (Agile Test Strategy) a while ago. There he mentioned Agile Testing Quadrants. Of course I knew them and had seen them several times before. I just couldn’t come up with the idea of them being useful in my current context.

I first used Crispin & Gregory Quadrants while describing our approach to one vendor. There was though many things that I didn’t personally see useful (e.g. Automated & Manual or ET being on Q3). Then I had a discussion with Jari Laakso on Twitter. After that discussion I realized – with the help of Jari – that I can modify the Quadrants in any way I want. And that I did.

Things I want to emphasize

With my modified Quadrants I want to emphasize basically 4 things:

1. Our testing being a division between testing the expected vs. unexpected – Or in other words ‘Focusing on Expectations’ vs. ‘Focusing on Risks’
2.  We are intentionally not focusing on testing certain things (e.g. unit testing) – but are aware of how that’s being done by certain people
3. All testing is based on exploration – in other words: Learning. We don’t test for the sake of testing, but to learn more about our product with every test
4. Testing mentioned on the top is about People and not only about Business. It’s about people whose lives our product touches (Marc McNeill – according to Dan North)

What was challenging

Perhaps the biggest challenge with Quadrants is that it’s quite challenging to fit different forms of testing there. For example in performance testing we might be testing the expected (e.g. explicit documented requirements), but also regardless of those. That would mean that performance related testing goes to many places.

In the end I found that that particular challenge was something I can live with. Considering I can emphasize those other things with the model.

What next?

I don’t know yet if I will continue to modify and improve the model to make it more useful while describing our testing approach. Or if I will use this model later on the following projects or companies. I might. Or I might not. What matters now, is that it makes it a bit easier (from my perspective) to explain what our testing looks like.

Visibility of Our Work

It’s been a while from my previous blog post. I’ve been busy with my current project which is actually my first as a consultant. This means that I’m learning all the time a lot and my thoughts around testing are evolving. When I activated on studying testing on March, 2012, I had a clear goal of becoming a software testing expert. Since then I’ve been for example on BBST Foundation and Rapid Software Testing courses. My knowledge about testing has increased hugely from what it was one year ago. I have though run into a problem. The problem is the visibility of our work. In other words, to whom and how much should we transfer our knowledge as testers?

Testing provides information

Image via (Marco Bellucci – Flickr)

I like the idea of testing providing information. It sounds natural for my current context that does not have any outside pressure affecting the way we test our system. Reporting bugs is the common way of delivering my knowledge about the system, but I can do more. At least I am trying to come up with different ways of being more valuable as a tester in my project. Basically that means thinking of to whom and how I could give information about the system I test. This can mean informing developers about the condition of the release or providing my opinion about the state of the system to product owner. Both are something that I have done in my current project.

With information comes responsibility

The information itself is rarely valuable to us only so we have to share it. I’ve experienced moments when filing every bug would have damaged a lot my relationship with the developers. James Bach has talked about Sympathetic Testing on his blog and how that is most often a way to start when facing highly unstable product. In other words not putting too much pressure on the product but more like trying to find out what it can do instead of what it can’t do.

Image via (fresh_photo – Flickr)

So we have to consider what information we provide and when. Especially this is highlighted when you are sharing information about your understanding to people that do not necessarily understand testing. These people might be for example from upper management or product owners. I reported some time ago my opinion about the overall status of the system I was testing. So, basically I just had to describe how I see the status of the system from tester’s perspective. I reported my opinion to several people across the project in one email and I had to make an extra note about how my opinion should not be viewed as final truth. That is why I think we should remember the impact that our information sharing can create. We are responsible for our words and should remember this all the time we talk about our opinion about the system under testing.

When we understand our responsibility we can make a change

The information we have about the system is by no means the truth. It is fallible and biased, but still a result of thought process that is often valuable to stakeholders. When we understand these aspects of our testing – and remember our responsibility toward our information sharing – we can share our knowledge in a way that will benefit the project more than solely relying on bug reports could achieve.

Image via (ForestWander – Flickr)

I also believe that in information sharing and visibility of our work lies the answer to changing the public opinion about testing. The better we evolve in explaining what we do, what we have found out or what we are about to do, the more people see the effort we have put to become a skilled tester. This requires though improving our way of explaining problems, clarifying our messages and treating for example every email or document as one that can be forwarded to any stakeholder on a project. I’ve seen the benefit in this when I have put a bit more effort in explaining things as simply and professionally as I can. And when my explanations are bouncing across the project, I can rest assure that it’s piece of my work like any other testing artifact I have produced (e.g. notes, bug reports).

What, Who and How

I do believe – based on my short experience – that the information we reveal via testing can be shared in various useful ways, but the challenge and my original problem is the ‘What, Who and How‘. What do we share (e.g. overall opinion about the system, opinion about a specific feature or functionality)? Who do we share (e.g. all the stakeholders, development team, upper management, product owner)? How do we share (e.g. email, mind map, meeting)? This is also one of those matters that is highly affected by the context, so there is no “One size fits all” -answer for this.

I will continue experimenting with the ‘What, Who and How’ -problem. I also hope I will be able to create conversation around this subject as it’s a lot linked to test reporting itself. Both are my main themes for year 2013 and if everything goes well, at the end of the year I can write “Part 2” post for this one with more wisdom behind it.