London Tester Gathering Workshops competition!

The London Tester Gathering Workshops are approaching and they are shaping up nicely.

To read a little bit about previous days have a look at these posts:

London Tester Gathering Workshops - Stephen Janaway
Lessons From The Black Ops Testing LTG Workshops! - Dan Ashby
Using games to aid tester creativity - John Stevenson
Focused Awareness - Simon Knight
Experiences of LTGW Workshops 2015 - Dan Ashby
LTGW2014: resources from our workshop - Carlos Ble
Announcement: Workshop & ebook: “Fast Feedback Using Ruby” - Stephan Kamper

Taking a page out of Richard's book I've decided to have a competition for 3 tickets to the Workshops.*

To enter you have to fill out the form:

• Explain why you want to attend.
• If there is a particular workshop you're interested in? And why?
• What do you think is missing from the Workshops?
• After the workshops write a blog post about the experience.

The form.

Not all the questions are mandatory.
* The competition is for a single ticket so there are 3 chances to win.
** Travel/accom. is not part of the competition. You will need to arrange and fund that yourself.
*** I have not needed to purchase these tickets as I organise the workshops.
**** Competition ends midnight on the 30th April.

A BDD lesson from my past - Part One

So, a few years ago I was involved in an agile transformation.

I was part of the consultancy brought in to work with a client.

As part of our learning through trial and error, we decided to try Behaviour Driven Development.

I wanted to learn from what we went through and share it with others.

I also wanted to learn what some of the people on the client site learned.

I worked with two separate people and we came up with 2 talks.

We worked with the same theme but taking their different experiences and personalities we created different talks.

It worked quite well.

Thanks to @andrewjutton and @brightoniant for joining me on this exercise and also being willing to go through their first presentation experience with me.

Recently @friendlytester wrote a post which reminded me of that time.

His post prompted me to write this post.

Are you sitting comfortably? Good. Then we'll begin.

Many moons ago, a few people came across SpecFlow and this lead them to Behaviour Driven Development.

We didn't spend time thinking through exactly what we wanted to achieve, or how we'd know if we were getting there.

SpecFlow, however, was shiny and new and we were still working on how exactly we were going to use automation in testing. 

We were lucky that people with the business knowledge were available.

We were unlucky in that the people with business knowledge were offsite most of the time.

We decided to trial BDD, which was driven by the tool and by the 'Software makers', which at the time did not include anybody from the business.

This (now) seems wrong and didn't work as effectively as it could have.

I have no evidence to back this up, but I believe that having the business suggest the idea of BDD would change the approach completely. 

BDD is about focusing on collaboration, not focusing on a tool.

You can work with BDD without ever using automation and receive plenty of value.

In-some cases you'll be better off as you won't get lost in the tool and focus on the collaboration.

Collaboration is the key and point.

So, there we were; Giving it, Whening it and Thening like mad.

Mostly written (solely) by the Business Analysts and therefore bypassing a shared understanding and attempting to share one person's understanding.

Here's an example:

Scenario: Display ‘Insurer Selection’ screen

Given that Insurer selection screen has been invoked
When the Insurer selection UI is rendered
Then the ‘Insurer Selection’ page is displayed
And the ‘Risk Variation Name’ field is displayed
And the ‘Risk Variation Name’ field is selected
And the ‘Customer Name’ is displayed
And only breadcrumb ‘Select Insurer’ is displayed
And all insurers setup in the system for the policy type are displayed
And all insurers setup in the system for the policy type are not selected
And the ‘Next’ button is disabled

We were learning.

We hadn't quite grasped yet that the how wasn't important, it's the what that is important.

What is actually trying to be completed?

End of part one.

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: Gaining wisdom

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.

Reasons to come to Agile Dev Practices

Program Overview

1. I'll be there.
2. Good mix of sessions.
3. Good mix of tutorials.
4. Good range of subjects.
5. Did I mention I'll be there?
6. Good range of workshops.
7. My colleague Ant will be there.
8. 25% off with code ATDC4P_025.
9. Potsdam/Berlin is great.
10. Markus can sign 'ATDD by Example: A Practical Guide to Acceptance Test-Driven Development' for you.  
11. You can talk to Gaspar Nagay, main contributor of the open-source .NET BDD tool, SpecFlow. 
12. Ellen can sign one of her books for you.
13. You can talk to Chris Matts and Olav Masssen.
14. Díaz & Hilterscheid have put on a great event.
15. You can talk to people who make software from all over the world, share your stories. 
16. You can teach.
17. You can learn. 

There are more reasons, what am I missing?

Total awareness of conditioning

How do I free myself from my conditioning of the culture in which I was born? First, I must be aware that I am conditioned; not somebody telling me that I am conditioned. You understand the difference?

If somebody tells me I am hungry, that’s something different from actually being hungry. So I must be aware of my conditioning, which means, I must be aware of it not only superficially, but at the deeper levels. That is, I must be aware totally.

To be so aware, means that I am not trying to go beyond the conditioning, not trying to be free of the conditioning. I must see it as it actually is, not bring in another element, such as wanting to be free of it, because that is an escape from actuality. I must be aware. What does that mean?

To be aware of my conditioning totally, not partially, means my mind must be highly sensitive, mustn’t it? Otherwise, I can’t be aware.

To be sensitive means to observe everything very, very closely; the colours, the quality of people, all the things around me. I must also be aware of what actually is without any choice. Can you do that?

Not trying to interpret it, not trying to change it, not trying to go beyond it or trying to be free of it; just to be totally aware of it?

Jiddu Krishnamurti - The Awakening of Intelligence

Why would I need excuses?

Recently uTest posted "8 Common Excuses in Software Testing" and within the comments there was a link to "Excuses for testers when bugs are caught in later testing cycles/UAT/Production".

My immediate thought was 'WTF? Why would I need excuses?'.

Reasons, yes, explanations, yes, but excuses? Hell no.

Am I wrong? Do I need excuses?

Or am I getting reasons and excuses mixed up?  Are some people taking them to mean the same thing?

At the end of "Excuses for testers when bugs are caught in later testing cycles/UAT/Production".  There is this sentence 'Well these are not actually excuses. These can be the actual reasons why an application is shipped to client with major bugs.'

The way I understand the two in this context are:

Reasons

1.a basis or cause, as for some belief, action, fact, event, etc.: the reason for declaring war. 

2.a statement presented in justification or explanation of a belief or action.

Excuses

1.to regard or judge with forgiveness or indulgence; pardon or forgive; overlook (a fault, error, etc.): Excuse his bad manners. 

2.to offer an apology for; seek to remove the blame of: He excused his absence by saying that he was ill. 

3.to serve as an apology or justification for; justify: Ignorance of the law excuses no one.

I am not a gate keeper, I am an information provider, I have limited time to provide what information I can.

I will do my best, the people around me will do their best and sometimes we will not be able to investigate everything.

I'm happy to explain things but make up excuses?  I think that will do more harm than good.

There are plenty of reasons why issues end up in production, learn from them, explain, improve how you test and what you test.

Don't make excuses.


28/01/13 Update.
Forgot to add, what and how you are testing and what you are not testing should be communicated and continuously communicated as you delve deeper into the software.

Weeknight Testing....BRB..

So a while back a bunch of clever people started this thing called Weekend Testing. 

About us
WT formerly known as Bangalore Weekend Testers is the acronym for Weekend Testers. We are a group of testers who have synergy towards testing software and learning from it. We also belong to the group of testers whose vision is to improve the craft. We are bringing Weekend Testing through our first chapter – Bangalore Weekend Testers, to find people with similar synergy.
Mission of WT
A platform for software testers to collaborate, test various kinds of software, foster hope, gain peer recognition, and be of value to the community.

You should already be aware of it, if not, look into it. Good times.
 
And out of it grew Weeknight Testing.

Weeknight Testing slowed down as we all got busy with life and there hasn't been a session for quite while.

Sharath has been in contact and we're looking at reviving it.

If there is anything you would like covered or if you're interested in running a session let us know.

I think (tbc) we're going to be looking at running it in different ways, not sure exactly yet but I think we'll mix between in person and on-line sessions.

Details on a couple of past sessions:

WNT – Black Box Security Testing

Week Night Testing: Requirements analysis & testing traps

Weeknight Testing #04 – an experience report

Agile Testing UK:Weeknight Testing Live 

  - Live video streamed between Germany, San Francisco and London.

Get involved.

Test. Learn. Contribute.


Cheers

Tony.

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.

LTG Talk - Testing Without Testing - James Marcus Bach

James Marcus Bach spoke at the November London Tester Gathering which was sponsored by Test Partners Ltd and hosted by Skillsmatter.

Skillsmatter have podcast the talk.

What is the most important skill a tester can have and why?

Last year I was at Eurostar helping out with asking attendees a question, video is up now.

Thanks to Huib Schoots for the question.

A while back I wrote a blog post with a similar theme.
At the EuroSTAR Software Testing Conference in Manchester, after another very successful conference, we asked you, the software testing community, one question....

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

Tyrion Lannister - the agilist.

He is intelligent, witty and has skill for political manoeuvring. 


Because he is an outcast, he also has great sympathy for outcasts and the mistreated and helps them improve.

He is disliked by some and treated with respect by others.

He has lived and experienced all that life can offer him.

He has been on trial, adapted, worked out a solution and used only the appropiate tools to survive.

He meets hostiles and wins their support.

He adapts and adapts those around him.

He is adapt at bureaucracy.

He keeps his friends close and his enemies closer.

He learns strategy.

He learns from books, experience and people.

He is effective.

He is a surviver.

He is a leader.

He is agile.

Which do you have? A job or a career?

Last year there was a post in the (members only) Bug Free : Discussions in Software Testing Linkedin Grp called 'What are the different types of things that can be tested?' it was by Todd who had been considering a new job.

He had been looking at job descriptions and wondering about the terminology, the descriptions and the general wish list which is job descriptions these days.

Todd was also wondering if he had the right skills "Well that's the problem - a huge majority of job postings I see have skills I do not have. So I'm trying to figure out what skills I need to learn to help increase my job pool."
I found it interesting that a few people just started banging on about learning Unix, SQL, etc without actually taking the time to find out what Todd's interests were.
I kinda of figure that if somebody is interested in something they would start reading/learning about it regardless of work.

While it's always good to keep learning new things, is it better to learn things that you're actually interested in?
Turns out Todd is interested in UX and his partner is a Front End Developer, seems to me that he has a fountain of info right in his home.

I'm going to move on from Todd now and write about 'what should I learn to get a new job/progress my career' posts in general.
I think, you should just learn what interests you, if you have a genuine interest you'll learn rapidly and continue learning and if you can manage yourself this will increase your job/career progress by default.

Am I crazy? Don't answer. Who? Shhh not now.

I guess it comes down to whether you have a job or a career.  Maybe it is time to decide.  If you have a job maybe you need to look for a career.  Maybe you're not worried and are perfectly happy with a job.
To me the difference is your general day.

Job = Clock watch, time seems to move backwards, can't wait to get out of work.  I know plenty of people who have a job, they seem miserable, although it could just be the ones I know.

Career = Not enough time in the day, too many things that interest you, there is no clocking off. I know plenty of people who have careers, they seem happy. I think they are happy because they spend their days doing things they are genuinely interested in.

Which do you have?

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?

I have a idea, I'll over complicate things! Sweet.

The other week, I sent a link out to my tester colleagues. It was a link to Corkboard, I thought it'd be useful.

Alan Richardson, the Test Manager, came back a short while later to say he'd accessed somebody else's Corkboard, without being given the URL, took him 5 minutes, drop all the work I was doing and see how long it took me (well, I made up the 'the drop all the work part').

Timeboxing myself to 5 mins. I dove in.

I went straight to Firebug and Burpsuite and also looked at the source.

Had he managed to hijack a session? Work out a pattern for the URL's? Found something useful in the source code? Got onto the server?

After looking at the source code, using Burpsuite to check out the requests, using Firebug to look for clues I couldn't see anything that stood out.

I called over my colleague Adrian, or rather I stopped him on the way to the toilet, and we had a quick look together.

We used Burpsuite to intercept every request individually and look for clues, nothing stood out.

We stopped.

Spent about 10 mins.

Walked over to Alan and asked him how he did it, we tried Burpsuite, etc.

He said 'you're over complicating it, look' and he typed in 'corkboard.me/test' which brought up a Corkboard.

!$£%£$^£$^£!

Lessons learnt:

* Ask more questions before you start.
* It's very tempting to dive straight in, don't, take a minute to think.
* Keep it simple (alternatively start with the simple).
* If it's not something you're involved in creating then realise somebody else probably tested it and may have left 'evidence'.
* It's possibly to have 10 min test challenges.


NB. Not that it's overly important but when I started this post Alan was Test Manager, he now no longer is.