Archive

Today I was thinking more about the persona of the tester. Thinking about the people surrounding me, mostly developers in my project, but also my test colleagues that I hang around at lunch or in some coffee breaks.

A thing that struck me was that pretty much all testers that I meet are stubborn as nothing else. One thing that shows every time I meet my colleagues is that we never run out of discussions, we only run out of time. Mainly this is because none of us agree completely with the others, never! They are probably also the audience on this blog that can have the most different opinions on what I write. =)

So, is this a good thing, bad thing or a necessary thing for the tester? Yes

Well, if the tester would not stick to his opinion when advocating a bug, no bugs would be fixed when mr-I-never-do-mistakes-developer is on the other side. In this case the stubbornness has to be used for taking the leap towards the analyst or customer. But if its a bug that emotionally struck the tester, and he is being stubborn about it, it could damage the project just as much, if not more than the bug itself.

If the tester was not stubborn enough to continue testing the product, even if no bugs are found in a long time, the most serios and complex bug found at the end of a really long and complex test run would be still unfound. The same goes for the stubborn tester popping the why stack whenever there is anything fishy in the product. But of course, this would also become annoying for whoever has to answer these questions all the time.

I would say that all testers are, and need to be stubborn on their questioning. More stubborn than the products/people/processes around them. That excessive stubbornness and questioning makes a good tester.

When I first skimmed this headline and then the post, I thought that this guy had the same thoughts on the subject as me. But reading it a couple of times made me realized that the post was not about the same as I was thinking about at the time. Although I acknowledge everything in it as good stuff, and very much on the path of DET (Developers Exploratory Testing) that my colleague Davor spoke about at Öredev in Malmö and ExpoQA in Madrid this year.

With my post, I have a slightly different perspective on it, which has been growing in my mind and discussed in some different settings with some friends.

The other day I asked a dear friend/colleague of mine what he thought of when I said the words:
“explore>learn>adapt and then explore again”
He directly responded with: “Thats agile!”

To be clear on this, he is a very knowledged and skilled developer and scrum master, but like many developers he still has the eyesheds of not looking too much at the testing perspective on things more often than sometimes.

So what is the difference then between being agile as a tester and doing exploratory testing? And why does my colleague associate the same words with being agile, and big parts of the testing community would say its ET. I dont see much of a difference actually. In James Bachs rapid software course this is the summary of what ET is: “by treating learning, test design and test execution as mutually supportive activities that run in parallell throughout the project. ” To me thats pretty much like the shorter and more concise wording I asked my friend.

In a project I am in now, I have to deliver a test specification as a product of the testing. So how do I do? Well, I explore the product in some way to learn how it works, design my tests and document in my specification and at the same time execute and adapt to my next step of exploration. I would say that in my case, I am doing ET, and those are the exact words I asked my friend about. The funny thing here is that the wording had to be neutral from the word test, for him to understand the meaning of them being agile, but for the testing context they are the same as ET, at least in my opinion.

I know that most people that think of ET, think of a scenario where the exploration is done manually through a gui, like on a web page. I acknowledge that as ET as well, but I think that this common understanding of ET comes from the simplicity of describing it like this. That kind of description I think is the most common among developers trying to understand ET.

The harder thing to understand about this, is to see the testing as the iterative feedback loop that it actually is, which responds to the feedbacks of developing with TDD or actually any agile process. The loops are just different in size and visibility. In my project some of the loops are 5 minutes and sometimes it takes a whole day. For exploring a web site, the feedback is mostly about seconds.

To conclude the post, why not just call exploratory testing being an agile process approach to testing, instead of an approach to testing within an agile process. The latter being the most common description I have seen when talking about agile testing. You see the difference?

I have a long list of topics for blog posts I want to write. However there never seems to be enough time. Also, I have realized that having halfway written posts and not finishing them because of my quality mind is stopping me.

I want to be clear that I see the scrum master role as a full time job in most cases, so the person should not be appointed any “testing tasks” in the project.

Why tester as Scrum master?

Well, test driving your sprints would result in having quality in mind from the start when composing user stories together with PO or customer. This would create better testability and better overview understanding of the system.

I see both testers and Scrum Masters as information hubs in a way that no developer would think. They need to be able to communicate in all directions, project management, management, developers, customers etc. Through the diplomacy you need as a tester, usually there is a grown confidence speaking any cultures languages and adapt to the situation which is discussed.

I know that I have many other ideas around this subject, but hey, lets see if anyone has a comment on this so far.