The Blink Test.

...or how we went to ride the Valkyrie!

When you have to test big data amount, one useful test technique is called The Blink Test.

Basically it is about defocusing, and then looking at the patterns you see and try to find the glitch, the part that is different than the rest.

Depending on the shape of the data, you can unzoom a excel page, or look at data scrolling on your screen, whatever helps you to understand the system, instead of the data itself.

This morning we were at the local Honda dealer, they had set up a testing day, so customers could go and ask for a test ride on one of their bikes.

I had an appointment to test ride the new CB500X. a nice entry level motorcycle, with an affordable price that I could consider buying... if I ever would consider buying such a thing.

So we went to the dealer, and they had set up a table outside, where you would show you driving license, sign up some form regarding insurance, and then they would give you the key to do a ride with the rest of users.

When I showed the lady my driving license, I noticed that she had to fill up a paper sheet with a printout of some excel-like page.

I looked at the columns and they were... Number, Model, Name... I jumped at the name column and found my name, and at the model on my line was the expected CB500X (this was checking).

Then I looked for the rest of the models, and I noticed that there was one model with no name on the line (that's how blink testing works).
And the model was F6C (this is domain knowledge, as I already knew what model the F6C was)

So my question to the lady was: "Is there any rider for the Valkyrie?" (this was testing).
-"No", she answered.
And my next question was: "Can I change my bike, and ride it?" (This was adding a new test case, based on the context and my previous observations)
-"Yeah, sure!", she said.

And so we did! We went out and tested how this Flat six engine, 117Bhp,  300Kg bike performed.

Things that I liked.
 - It does not accelerate, it jumps into hyperspace.
 - It brakes like its rolling on rails, bringing you out from hyperspace in no time.
 - When accelerating, the sound that comes from the engine is awesome.
 - People look at you when you are riding it.

Things that I didn't like.
 - It is too heavy to ride at the city, this is not a bike to commute.
 - Because it has no fairing or saddlebags, I don't think it would be good for riding long distances either.
 - While I was riding it, I could not relax myself, I was too busy handling all that power and weight.
 - People look at you when you are riding it.
 - It is too expensive, starting at 23.700€ it is more than some testers around earn in a whole year.

But hey, if you don't try, there is no way of knowing!

Back from the ride, safe and sound.

At the end, my wife and I had a debriefing session, and we decided to continue with our good' old Vespa for a while.

It was nice to ride the Valkyrie... but now I wonder how the CB500X might be.

Back to the Blink Test, James Back has a nice post here explaining how it works. I invite you to read it, you never know when you will find it useful.

The #greentester contest.

Last month, the guys from Eurostar came up with a challenge to win a ticket to Eurostar.

This was the contest.

When I saw this, and as I was wearing a green t-shirt, I submitted my first pic, right from the office.

Guess were I've been!

I already had a chance, and this should be good enough, but rules didn't say anything about sending just one picture, and the next weekend, as we were playing in the park with kids and cousins, this one came out:

Support your team.

Two weeks passed and people started sending really good pictures, so now I was thinking about elaborating a better one. So I thought about giving a chance to the bike, and how to shoot a picture while riding it, and where to do it.

One morning, I took a small diversion on my way to the office, and went to a nice spot outside the city. I set up the camera and recorded a video while I was passing in front of the camera.
Out from that video came this picture:

It's a long way...

It might not result in the best picture of the world, but it was fun trying it out.

Then one night, I saw this video about how to fake a famous picture, and decided to give it a try. My model was David Hobby's portrait picture:

The Strobist.

I had the mac, and instead the sodas, I had a RedBull and a empty Baby bottle, so I started experimenting with the lights...

Test1 Test2 ...

 At the end, The one that I liked the most:

Make it green!

And? did I win? Hell no!, Maybe I got close, but +Michael Larsen submitted an awesome picture that got the price.

And about getting to the conference, well, I guess I could pay to get there, as +Jesper Lindholt Ottosen wrote, Left to my own devices ... I probably would.

The funny thing is that this happened before, last year I tried to get to Eurostar submitting a picture, and both Jesper and I almost got the price.

Learning and experimenting is what makes sense of trying things out, so next time I get the chance, I will be testing... and looking to the camera!

Testbash 3

... or how we managed our small British adventure.

The plan.

All this started in September 2013, I went to Brighton because +Rosie Sherry organized a affordable one day training about Rapid Software Testing for Managers, with +Michael Bolton.

The training went just fine (here) I met a lot of great testers, and I liked Brighton a lot. It is a nice small corner of the world, and many of the attendees talked great, really great about last years TestBash. Even my fellow tester +Mauri Edo went there and he got back with a enthusiastic post about creating community!

So, when I got back home, the list of the speakers came out, and it was just great! so I started making numbers to see how suitable it was to attend to this conference.

And then, because the conference was on a Friday, and because Brighton is a nice town, and because we enjoy travelling, I came out with a crazy idea, Why don't we all go to Brighton, and return on Sunday.

So, we booked a big hotel room for a small difference, some flight tickets at a reasonable price and the ticket for TestBash3. And we did all this back in September, so the planes and the hotels were as cheap as they can be when you book 6 months ahead.

The travel to Brighton.

We packed as little as we could, just enough to let us spend 3 nights out and have a chance to do a walk, and having 3 kids with ages 6, 4 and 2 that meant two strollers, 15 diapers, 4 boxes of wipes, some milkshake, pyjamas, some clean clothes, books to paint and stickers, just in case somebody gets bored.

And it went just fine, we arrived late at night to the hotel in Brighton, but we managed to get some sleep before next day.

The Conference.

Lean coffee 

 

The first event of the conference was a Lean Coffee, and at the time I arrived, all tables were set and ready. Chris George wrote a very nice post about how the setup was done, please check it out.

So, once we started we talked about testing automation, about development cycles, about communication issues, about regression testing and release schedules, about testers who code and developers who test... and we could have been all day sitting on that table, but we could not, because then it was time for the talks.

The talks

 

... or what did I learn from them...

Scott Barber told us about performance testing, about how to do it from conception to headstone, about performance being to load as rectangle is to square. For me this talk was a level down at the Orders of Ignorance, so now the challenge is on me to continue that path.

Mark Tomilson spoke about how our brains are working, why we need to focus and defocus in order to help ourselves getting to ideas, and to understand that we have to get our brains to go from the knows to the unknowns when we are doing testing.

Jez Nicolson explained that developers expect safety from the tester, while managers expect predictability, (pretty) graphs and less stress.
And that testers need to talk, with developers, managers and to the business people.

Joep Schuurkes helped us understand how to get a new tester on the team, with the example of navigating a new city, where you would like to get a map, some history, some advice, some guidance... Ah, and "Documents is the place where information goes to die".

Huib Schoots started talking about what testing was, and at some point he asked what was agile testing... So I raised my hand and said that It's just testing, but in a agile context. I found this definition at Meike Mertsch's blog and since my team is a agile team, (as agile as we know how to be), and I am the tester... (as good as I know how to be) I totally support this definition.
But being Agile simply means nothing... if you don't support the values that are behind those principles..

Bill Mattews showed us how to apply the business model canvas to our testing. And for me, once again, this was another step down on my Orders of Ignorance, I simply didn't know that such thing was possible.

Stephen Blower told is his history for this last year... and boy, what a trip he is been to! Basically after spending a lot of years testing he found out why he was testing and what this was all about. He encouraged us to DO SOMETHING!

Iain McCowat focused on tools, and how the tools we use are shaping us. He gave a nice talk, and I got out of it that WHY? is the best question a tester can do.

Chris George gave us a talk about a real case of a optimization work. In his great talk he explained to us that after all, big problems are just a collection of smaller problems.

Keith Klain explained to us the basic rules to follow when talking with our company C*O, and they are just two:

• To tell something you want them to DO.
• To tell something toy want them to KNOW.

He also explained the reason behind... with a powerful presentation based on [They|We|You] Suck theory.

The last talk was a 99seconds lighting talk, and these were great, just great!

The rest of the conference...

 

• While the talks were delivered, we had some mentions to Jerry Weinberg, but also many to James Bach and Michael Bolton.
• The food was vegetarian!
• I noticed a lot of female assistants. At the conferences I been to in Spain, I guess that the proportion about male/female assistants could be around 6/1, while at testBash this was close to 2/1 which is a very good balance.
• I talked to many people I was following on twitter/google+ and this was a really nice part for me, to get to know the human part of all those I consider my fellow testers from places around.
• The pictures I took can be found here
• +Blogger, shame on you! for making me write this post twice!

The Trip to London and the return home.

The next day we went to London. We took the train and walked from Victoria station to Trafalgar Square and to the London Eye, we had lunch nearby and then took the tube to Lancaster Gate and went to Hyde Park.
After sitting down for some ice cream, we then took a walk all the way down to Victoria station and that did the day.

We saw Ducks, Squirrels, Soldiers riding horses, Police cars, Sport cars, Two-deck buses, Monuments ( a lot of them ) to men who fought on the British side at many wars... And at the end of the day the kids were still having fun on the train back to Brighton.

On Sunday we had the chance to meet Adrian, our former devOps at peerTransfer who is now working in Brighton, and after some Fish&Chips at the beach we headed back home.

Was it worth?

As a tester, I was able to attend to a conference that was much more than a conference, it was the gathering of the software testing fellowship!

As a father, I was able to show my kids a little about how big the world is, and how different other places are.

Doing a story review

One of the changes we are doing on our process is that now more people will review the user stories before we start coding.

It's good to read.

It all starts with a problem that somebody has, this problem gets to the Product Manager who has to write it down so that the developer knows what he should fix. But because things can get complicated, details and context can be lost in this process, that's why it is a good idea to review this writing, to identify what the implicit and the explicit understanding is about.

Some time ago, I found a nice checklist to use when doing a story review.

What to question when doing a story review:

1. Is this story solving a problem?
2. If so, what is the problem we're trying to solve?
3. Could we implement a solution that doesn't solve the problem?
4. How will the story add value to the business?
5. Who are the end users of the feature?
6. What value will they get out of it?
7. What will users do, right before and right after they use that feature?
8. How do we know we're done with this story?

It came out from the Agile Testing book, by Lisa Crispin and Janet Gregory. If you think the list is good, I invite you to read the whole book.

The picture of astronauts reading comes from this page.