Explaining testing: 101 Tactics For Revolutionaries

Here are the first 10 to get you started.

Onward to glory!

1. if you’re in charge, do it yourself
2. if you’re not in charge, do it yourself
3. become known as “the guy who…” so when the time is right, everyone knows there’s a guy who…
4. learn to be nice, so people like you
5. realise there are no rules, you can do what you like
6. know that you are as right as you can be for now given what you’ve learnt so far
7. know that this is the same for everybody else
8. stay on the inside of the wrong thing so you can speak with authority on why and how it is wrong
9. know it’s not a race. That you can divide the world into those ahead of you and those behind, and to all those ahead of you, you’re the one behind.
10. be an entrepreneur not a crusader

The rest are here: 101 Tactics For Revolutionaries

Explaining testing: agile testing

Pete Walen asked this question: For software testing professionals/craftspeople, what is it that differentiates Agile Testing from any other testing?
 
My reply: - I have wondered the same myself. And as with most things, it seems like it is contextual. It depends on what you're working on, who you are working with, what is available to you, who is available to you, etc.

It also depends on your mindset and behaviours. I think it's a openness and a willingness to learn and working together closely, perhaps closer than people from some environments are used to. You need awareness of yourself, and whether or not it is a place for you, things move quicker and you can't hide.

In some agile environments some of the Testers will be very technical and focus on automation and knocking up tools, frameworks, etc to help with the testing. But that doesn't mean that a Tester with different skills won't be able to add value. And ideally it's good to have a mixture.

I also think it's not so much what differentiates A/agile Testing from from any other testing. It's that Testers who have been doing the bare minimum are more exposed in a agile(ish) environment. Issue with that is that some people don't realise they are doing the bare minimum because they are doing what is asked of them.

People who have tried to change things, or looked for ways to improve things will probably be able to adapt easier to agile.

Those who have not been increasing their skill set, learning new things, etc can find it hard when things are moving quickly. Those who are used to spending days/weeks/months knocking up test scripts to follow may find themselves a little lost when they don't have that security blanket.

You need to be able to manage yourself and get on with things and in a more agile environment you are able to do so.

The thing is, there is no one, true, right answer because both 'agile' and 'testing' mean different things to different people so you get my rambley answer :-)

Huib Schoots has a excellent post about agile testing.

Inbetween talks - Agile Dev Practices 2013

So #agiledevprac has been and gone.

I had a great time.


During the Monday my fellow speaker Ant and I had a chance to hang out with Maik Nogens.

Maik's a great guy, if you see him (you can't miss him, he's 8ft tall, although everybody looks 8ft tall when they are standing next to me) say hi.

We had a walk around Potsdam and sampled a couple of Bratwurst.  This is my second time in Potsdam and I think it's a great place, nice, quiet and picturesque.

On the first night there was a speakers dinner at Walhalla.

Jose stood up and gave a short speech welcoming everybody.

The food itself was OK, the company was great.

Ant and I had both chosen a fish dish which came with bacon sauce. BACON. SAUCE. How could you not?!

We'd been waiting and looking forward to it for weeks. We'd been imaging all sorts of amazing creations.

It was one of the biggest disappointments ever. It is a cream sauce with bits of bacon in it.

Ant and I shared a table with a number of people and we spent the most time talking to Ray Scott and Vagif Abilov.

I've come across Ray and Vagif before in my travels but have never had a chance to sit down and have a proper talk.

It was great to do so.

After dinner there was a short visit to the hotel bar and then off to sleep.


Over the next few days there were:

• Pop-up coding dojos.

• Conversations all around with people from the world over.
• I would love to list the names of everybody I had a conversation with but there are too many.
• Ant drank his first ever full pint of beer, followed by his second, and third, etc.

 

• A social dinner event complete with improv comedy troupe.
• Ant and I were on the same table and again had a number of diners with us. During dinner we spoke mostly with Ray Scott and Krystian Kaczor. 
• After the meal we spoke with a few more people.
• A group of us went for a meal, sat down and realised none of us speak German.
• We had 2 English guys, 1 Hungarian, 2 Spanish guys and 3 Russians.
• Luckily, one of the waiters spoke Russian so we were able to get a meal organised.

 

Unfortunately I didn't get the names of two of the (Russian) guys at dinner, the rest are:

@carlosble

@brightoniant

@ooobject

@gasparnagy

@vgaltes

It was great to catch up with some people, meet new people, have some great meals and have some great discussions.


In my opinion, over the next few days there were some good talks, some OK talks and some talks that didn't quite work.

Conferences are essentially a meeting of people who want to contribute, teach, learn and share.

It's not just attending the talks.

Make the effort to meet new people and talk and you will get untold value from a conference.

It doesn't make sense.

I stole this, I changed two words:

People work with one set of ideas about how the software is. Everything they do, be it experimental or theoretical work, is informed by, and framed within, that set of ideas. There will be some evidence that doesn't fit, however. At first, that evidence will be ignored or sabotaged. Eventually, though, the anomalies will pile up so high they simply cannot be ignored or sabotaged any longer. Then comes crisis.
13 Things That Don't Make Sense - Michael Brooks.

To me, this is a pretty good explanation of software development, although of course, not in all cases of software development.

It's also a pretty good reason why things like agile, devops, devs, bdd, etc have come about.

We do approach things with a set of ideas and we do frame things with that set of ideas in mind.

We stick to our own ideas, even though some of our ideas have been born out of others' ideas and thoughts and words and we've blindly made them our ideas and thoughts.
- For more on this train of thought refer to Leprechauns of Software Development or various kinds of certification.

When we have ideas that we have actually conceived it can be a good thing because we all have different experiences, we all have different thoughts, we can all add something.

I think the problems occur when we don't let go of theses ideas (when beneficial) and learn from others experiences and listen to others ideas.

A lot of time we don't conceive ideas together for something we are supposed to be working on together.

What's wrong with us?

Doesn't make sense to me.

Make sense to you?

Continuing with the excerpts from 13 Things That Don't Make Sense The next paragraph starts with the sentence:

Crisis, Kuhn said, is soon followed by the paradigm shift in which everyone gains a radically new way of looking at the world.

Does it? Not for software development, not as much as needed.

In the context of software development the sentence would read:

Crisis, Kuhn said, is soon followed by a attempt to throw more people at, work longer hours to stem and follow the procedures that caused the crisis in the first place until the next crisis arrives.

What's wrong with us?

Should Testers Code? Blah blah blah blah.

Should Testers code?

I don't know.

If you want to code then code.

If you don't then don't.

Just remember to have the right tools for the job at hand and be mindful of limiting yourself.

What I will say is...........well I won't say it cause I'm stealing it from Gerald Durrell so what I will do is share with you a passage from The Amateur Naturalist.

What really makes a naturalist? Well I think that a naturalist first of all has to have a very enquiring mind.  He seeks to observe every little variation in nature and to try and discover its origin and function.  It was Sherlock Holmes who said, "You see, but you do not observe."  That is true of most people in the world today.  A naturalist must keep an open mind and be interested in many things, although may specialise in one particular subject.

 Does that resonate?

15/01/13 Update. Derek Sivers makes a good point.

Ted talk: Temple Grandin: The world needs all kinds of minds

Book review: Dealing with Difficult People

Dealing with Difficult People: 24 Lessons for Bringing Out the Best In Everyone.

Dr. Rick Kirschner(Author), Dr. Rick Brinkman (Author) 

From the back cover:

In every workplace there are difficult people who, at best, make life stressful and, at worst, can keep you from achieving important goals. But it's within your power to bring out the best behaviour in people who are their worst.

If you are interested in working with people more effectively or work with quirky people and aren't sure how to deal with that this book is good place to start.

The book breaks up what it lists as the 10 most unwanted behaviours:

The Tank

The Sniper

The Grenade

The Know-it-All

The Think-They-Know-it-All

The Yes Person

The Maybe Person

The Nothing Person

The No Person

The Whiner

You can pretty much guess the behaviours of each from what they are called and you probably have already matched some to people you know.

I kind of think we all have a little of all of those within is.

The book starts with some initial general ideas for dealing with all 10. Things like:

Understand that everybody reacts differently to these types of behaviour: The person who's most irritating to you may be perfectly acceptable to someone else.

It then goes into Choosing your approach, then understanding the behaviours and intent.  Four intents are written about:
get it done
get it right
get along
get appreciated

It delves a little deeper into communication and briefly discusses things like blending and redirecting. Pygmalion power is also mentioned.

After that it starts focussing in on the list of 10 and digging in deeper to each one.

I found there were some mixed messages, in some sections there are statments such as 'There's no magic formula; you are the best judge of which choice is right in any particular situation' and in a different section there is the following 'Here is a surefire five-step process to break your Nothing Person's silence'

All in all it's a good starting point if you are interested in this kind of thing.  

Read it, ingest it, think about it.

Really? You can't replicate this?

Sometimes, things happen that seem quite straight forward, quite obvious and quite easy to repeat

And sometimes they are only quite straight forward, quite obvious, and quite easy to repeat to you.

I had a fault with my ASUS EEEPAD Transformer.

I reported it.

NB. I don't have the original report but I asked them to send me a copy and this is apparently what I wrote "memory card slot shoots the card back out"

Now, not a long description but I thought I had written  enough.

I was wrong.

They could not replicate it.

They sent it back.

They did not contact me first before sending it back.

They wiped the system.

I'm not sure why they would even have to turn it on for the fault that I was reporting but what do I know?

The report details read 'test ok/no fault found.'

I emailed back requesting details of their investigation as the fault was still present.

I did not receive details of their investigation, I received no response to that request.

I did receive a request that it be tried with another memory card which I had already done.

I also had not realised that a batch of memory cards with thoughts of freedom had been realised.

I did receive a request for a video of the fault.

I made the video.

There is only 1 memory card slot on the device and it only takes 1 kind of memory card.

I thought this would be easy to replicate. And it is. But not for everybody.

For some unexplained reason I then had to raise another support request.

Device went back and came back.

Fault stated to be fixed.

Do I trust them?

No.

Do I now have duct tape over the memory card slot?

Yes.

Lessons learnt:

Easy and obvious is only easy and obvious to you.

If you can back it up with a video do so from the start.

If something is reported and you can't replicate it contact the people who reported it. It was reported for a reason.

Take and keep notes.

This is the video, could you replicate this?

Testing? Thoughts? Idea? What?

Yesterday I tried a experiment I'd been toying with in my head.

I've been with a organisation for roughly 8mths now and I've not actually had a lot of time to spend with the Testers as we've all been busy and I wanted to know more about how they think and what they think about what they do.

My role has changed slightly now and I have more time to work with the Testers and so yesterday was the first of the 'sessions' I'll be running.

I had 3 Testers on the exercise and essentially just asked them to write down thoughts on testing.

We then discussed what they had written down and wrote it on a whiteboard.

I then added to it with my thoughts which we also discussed.

There were notes being taken and thoughtful nods and comments.

Mine are in red.

Francesco, a colleague who wasn't on the exercise later pointed out that we'd not written anything about 'who'.

What else did we miss?

I think the session was a success as it seemed to get the guys thinking and I learnt about their thinking.

I would like to punch it up a bit, not sure what I could add to jazz it up a little.

Have you run anything similar? Or taken part in something similar? How did you get on?

It might have worked a little better if thoughts had been written the night before and then we got together to discuss as I'm thinking of new stuff to add all the time.