What I got back from EuroStar - Restore to Factory Settings: What to Do When a Change Programme Goes Wrong by Isabel Evans

Since I attended the EuroStar conference, I would like to write down a little about talks I went to, just to put together notes, pictures and toughs.

Restore to Factory Settings: What to Do When a Change Programme Goes Wrong by Isabel Evans.

Isabel started her talk explaining what influence diagrams were about. And since the example found at Wikipedia is TLWR, she used a simple example.

She told us that when she gets sad, then she eats chocolate.
when she eats chocolate, then she gains weight.
When she gains weight, she gets sad.

And expressed this with a simple influence diagram.

Instead of using a mindmap where some items are related or belong to some others, in a influence diagram there is a circular relationship between all elements, creating a ecosystem of influences that helps us understand change, or why things got to a certain state.

Once this was clear, she moved on and explained how she started working for a big company with the mission of improve testing, and how she found out that it was not enough to improve testing, but that a lot of global improvements across the whole company had to take place in order to improve testing.

Check out her initial plan in green, and the influences she found out that were happening in red:

Also, she found out how the influence of management was impacting the developers, and came up with another nice diagram:

At the end of her talk, she linked her example to Joels law of leaky abstractions and how this law does not only apply to software, but also to process and relations inside the company.

What I got out of it:
I wasn't aware of influence diagrams as a powerful tool to explain circular cause-effect conditions, but since this talk, I think it's going to be a new tool in my belt.

At our peerTransfer office we have a nice influence diagram about development speed, just by the coffee machine.

You can find Isabel at Twitter, there is a nice interview at the Ministry of Testing and you can listen to her keynote at the EuroStar site.

What I got back from EuroStar - Every Tester has a price, by Michael Bolton.

Since I attended the EuroStar conference, I would like to write down a little about talks I went to, just to put together notes, pictures and toughs.

Every Tester Has a PRICE: Sources of Product and Project Information by Michael Bolton @michaelbolton.

This man has taught me a lot about Software Testing, so attending to his talk was in my plan. Not because I haven't been to any of his talks before, but just because I knew I'll learn something out of it.

Michael is also a musician, and the way he performed his talk reminded me a lot to those times when musicians gather together to teach and learn from each other, first explaining what they are going to do, then doing it slowly and finally playing the whole set so the music sounds with it's intended form and the harmonies happen to make total sense.

We went to the room at the conference, and it happened to be totally crowded, so after a glance he decided that whatever format he had planned for his talk wouldn't work, so he improvised using a laptop and xmind a tool for doing mindmaps.

He talked about handling expectations, about how for a single test you should not expect a single result, about how requirements live in collective heads, in collective tacit knowledge.

And then he asked the assistants to outline where a tester could gather information about testing, and many things came out, like Requirements, Competing products, Marketing campaigns, Regulations, Bug reports...
At some point he had his screen full of items, (about 50 of them) you could use to get information about what you should be testing and making questions about.

But all these items were messed around the screen, so the eureka! moment came when he told us that there are four types of Information:
- Reference: Information that is written somewhere.
- Conference: Information that you get when talking with people.
- Inference: Information you get when you use something, or people use to do in a certain way.
- Experience: Information you got from experiments you did, or from things you know how to do.

And he allocated each of the items to one of these four types, explaining how each one could belong to a certain type of information and making totally sense out of the previous mess.

What I got out from it:
Well, I already knew how important it is for a tester to have information about what he is testing, what the context is about and what matters and why. Bolton reminded me that when I search for information, there are a lot of places to go and to have in mind, it's just a matter of using your imagination.

I haven't found this talk at the internets, but if you are curious I can recommend you his talk about Agile Testing Quadrants and maybe, to check in his page and take a Rapid Software Testing class whenever that might be. I took that training in May 2012, and it set my testing career looking (so far) at the right direction.

What I got back from EuroStar - The Internet of things.

Since I attended the EuroStar conference, I would like to write down a little about talks I went to, just to put together notes, pictures and toughs.

The Internet of Things by Andy Stanford-Clark @andysc 

Andy explained to the audience what the so called 'Internet of things' is about connecting to the internet devices that traditionally didn't have connectivity.

This idea is hitting the big industry, and he used his own example of how his family is measuring their home energy consumption, how he collects the data, analyse it and learn things out from it.

To put it short, he developed a series of devices so he would track the electricity consumption, open windows, weather forecast, temperature, mousetraps and some system behind that would tweet any news regarding his home. (things like "living room window has been open for 3 hours", or "Mouse trap in studio just caught a mouse", you get the idea...)

And over the layer of measurements, he added another layer of intelligence, so his home would tweet advice to set the washing machine on, based on current electricity consumption and a good weather forecast.

What he was explaining, is that business of any kind need to find new ways to deal with customers. Be that by connecting devices to the internet, offering services in the cloud, by managing data or by providing intelligence.

He explained us how his future was like, and he warned us, that one day, your toilet is going to suggest you to visit the doctor, and your insurance company is going to offer you such a toilet.

What I got out of it:
I loved to see how Andy was able to put together simple solutions to deal with a complex problem, that's engineering at its best state. I also got a curiosity about how much energy our home is consuming, and I'm considering trying out some the stuff that can be found at efergy or opendomo.

PD. I found a similar talk Andy gave at a TEDx event, it's not exactly the same, but it might be worth 16 minutes of your life.

 

Thank you for EuroStar 2014

Last week I went to EuroStar conference in Dublin, and it was a blast!

Dublin Conference Center

I have to say that this was totally unexpected to me. I tried to win a ticket at the greentester contest, but didn't make it, and even that I have a budget for trainings and conferences, EuroStar was just too much for me.

But then, one month ago, Rosie Sherry emailed me asking if I would go to Dublin if she managed to get me a ticket, and my answer was "Yes, sure!".

So, the conference has been grand!, I attended to great talks, knew a lot of people and had a lot of fun.

But first things first, I have to say Thank you...

Thank you Rosie Sherry for getting me a ticket to the conference, I had a great time in Dublin and it happened to be a great experience.

Thank you Morten Hougaard, who came up with a ticket for the gala dinner, so I could join the crowd in this event.

Thank you Michael Larsen, for sitting down with me, letting me complete a challenge and providing a Miagi-Do brown belt which I will wear with honour.

Thank you to Emma, Guna, Ru and the rest of the Test Lab folks for making the lab the best place to be in the conference. Perfect to practice stuff and complete challenges. Hugo and I were able to solve the black box, and the feeling of satisfaction was worth the struggle.

Thank you to the people behind the EuroStar conference, I saw you all working very hard so the conference would be a success, and because it was, you deserve every nice word about how it went.

Thank you to my team at peerTransfer, for testing all issues that came to my kanban slot while I was at the conference, so when I got back to the office I didn't have a mountain of issues waiting to get tested.

You people rock! and I am grateful to all of you for this experiences I had.

And last but not least, thank you Empar, my beloved wife, for rowing my same boat, in the same direction, for running our family while I'm miles away,

My plan for the EuroStar Conference.

There is a quote I like from George S. Patton: "A good plan violently executed now is better than a perfect plan executed next week."

Next week I expect to be at EuroStar conference in Dublin, so I need a plan, and better if it is now!

I have checked Rob Lambert's Unnofficial Guide for attending EuroStar.

I made my Checklist:
Business Cards.
Camera && Charger.
Notebook && Pencils.
Map of budget car parking location && Plane ticket.
Laptop && Charger.
Phone && USB cable.
Electric plug adaptor, as Ireland has the same plugs that British do.
... and the rest of the stuff you take when you go 2 nights on travel.

I also have a plan for those talks that seems interesting to me:

It's not a perfect plan, and it won't happen like that for sure,  some things are going to change, but that's okay, after all, as Helmuth von Moltke the Elder once said: "No plan of operations extends with any certainty beyond the first contact with the main hostile force."

It's not just a watch.

In November I went to Brighton for a one day mobile testing training. This subject is getting interesting to follow, not because it's the future, but because it's the present, just that many choose to live in the past.

One of the things we talked about was the future of mobile devices, and here it seems that we will face three tendencies.
New phones, with new features, screen resolutions, sensors, operation systems and so on..
RFID sensors everywhere, at supermarkets, trains, stores, cars...
Wereable devices, and here comes my story...

Two months ago I needed to change my watch. My old Casio broke its glass and water was making the way to the inside case, getting it difficult to read, so after searching a bit around, I decided to get a Garmin VivoFit.

And, just for trying it out nicely, I got a spare one for my wife, so we both started experimenting with this wereable device.

The gadget is basically a pedometer that you wear in your wrist and also gives you the time of the day, so I didn’t have to get a new watch. But it does some other things too.

It has a little red bar, that comes out when I been sitting down for more than 1 hour, warning me that I should start thinking about getting myself back on the move.
It also keeps track of how many steps I been taking, and every day he suggest a goal, based on my previous days, so I know how many steps I am missing for the day.

These features can be useless if you decide to ignore them, but if you don’t, they keep you walking to the office and not taking the elevator when you get back home.


...And when you set up your age and weight, it can calculate the calories you are burning as you go, so you have a measure about how you are doing today. Here is where the fun starts.

To put it simple, let’s say that our body needs calories to burn in order to perform any activity, so, it burns calories when we walk, when we run, but it stops burning calories when we sit down for a while.

Available calories can be refilled into our body by eating and drinking, but some food has more calories than others, so water has none, fruit has a few, cookies and soda have a lot of them. If you eat too much and exercise too little, you body has to keep these calories somewhere, as I noticed last summer when I had to get a new pair of jeans with a larger waist size.

So the point here is to keep track of how much you are burning and refilling, just to know where you stand.

Still this gadget doesn’t measure it all, because it’s a simple pedometer, it can not detect when you are cycling, or swimming… for these I use Endomondo so whenever I choose to ride the bike I can still keep track on how much sugar I might be burning.

This is cool to keep track of the burnt calories, so what about the ones I am eating?

For that we found MyFitnessPal, a nice collaborative app where you can keep track of what you are eating and how many calories that is supposed to contain.

And the great thing here is that these 3 apps can sync together. At the end of the day, I can get a estimated balance about how I am doing.

Off course, all this is based on guesstimations, but it’s okay as long you are aware, I just want to know if I been walking too little, or eating too much, I don't need too much precision on this.

Some people have healthy habits, they understood time ago, that if they wanted to keep fit, they needed to watch out what they were eating, and they also needed to do some exercise, I think this gadget can be pretty useless for them.

But for us, my wife and me, it quite helps having a little control of how we are doing, and once we got some numbers, we started walking a bit more and eating a bit less.

This is the start of our journey into the wereables, two devices and three apps that communicates with each other, storing information in the cloud and providing information to users across many platforms, and this is just the beginning, just wait and see.

Mobile Testing with Stephen Janaway

This November I went back to Brighton.

Rosie Sherry and The Ministry of Testing have come up with two weeks of awesome training events, but given my limited budget, I had to choose one day to attend, so this time I went for the Mobile Testing day.

The trip went just fine, as I bought my tickets early, I could have a cheap flight from our sunny small town airport in Valencia...

...to the big and rainy one in Gatwick.

Once in Brighton, this training thing had two different events, One was attending the training day, and the other was hanging out with testers.

Mobile Testing with Stephen Janaway.

For this training session we sat down in groups in big round tables, so we had plenty of space to talk and to take notes. Stephen had some slides supporting his talk, and there were whiteboards so we could draw things at the exercise times.

We talked among others about:
What mobile was about, and why we should test on mobile.
What mobile testing was about.
What submitting to app stores was like.
How to approach to Mobile Testing automation.
Why you should test on the train instead of the office.

We did some work about:
Drawing a mindmap about how we would test a app that would take pictures.
Ponting out differences on the same app while running on different OS.
Testing real life apps looking for real life bugs.

At the end, testing is still testing, so when it's about a feature, all learnings and knowledge a functional tester has are valid.
But because it is hosted on this mobile device, the context changes and impacts a lot, this requires to focus on it, understand how it impacts and spend time testing it.

It's not just a device with a smaller screen.

If you are interested in mobile testing, I can recommend you this video and this book, as well as joining Stephen in his next training session wherever that might be.

Hanging out with Testers.

Because these training days are happening in a row, it happens that if you reserve some spare time, you can hang out with the testers that came for the previous day session, and with those who are to join the next one, so I had the chance to meet a nice bunch of testers.

I had a great time in Brighton,  and I'm really looking forward for Testbash2015

Getting Tomislav to CoCo2015

The Copenhagen Context conference is getting ready for it´s next years session, you can check their site here: http://copenhagencontext.com/

One of the things they come out with is the chance to get a free seat on the conference. The rules are quite simple, record and upload a video somehow related with this years theme: "Let’s take context-driven testing even further."

My approach to get Context Driven Testing further, is to get more Context Driven Testers in town. Since the only other Context Driven dude I know in town is my friend +Tirtharaja Dasa I recorded this video:

The funny part is that he didn´t know that I was going to ask for a place for him, until the camera was recording, but hey, we are testers, we have to try.

*This video got selected, so Tomislav is making it to the conference.
Thank you all for your support!

The Schneider Trophy.

Let me introduce you to Jacques Schneider.

Back in 1911 he thought that seaplanes had a great future since so much of the earth is covered by water, so this successful French financier decided to create a competition, a race between seaplanes where the rules were quite simple:
- A Triangular course was set over the sea, and the fastest seaplane that would complete the course would win the trophy.
- After some years running the competition, they came out with a second rule, the winning seaplane had to remain moored to a buoy for six hours, without human intervention.

Once these rules were set, many design companies from around the world would create a seaplane that would race trying to get the Trophy.
The race happened eleven times between 1913 and 1931, and the trophy itself is nowadays exhibited in the London Science Museum.

On the first race, the winning plane was a French Deperdussin, that managed to complete the race with an average speed of 73 km/h.

But once the competition was set, every year, new designs from France, Italy, Great Britain and the United States would try to get a faster plane, with better aerodynamics and more powerful engines.

In 1931, The last year the competition was hold, the Brits won with a Supermarine 6B, She completed the race with an average speed of 547 km/h.

After 18 years of continuous iterations, where every prototype was faster than the last one, where engineers would learn what happened when they tried out new wing design, new engines, fuel injection, aerodynamics, wind tunnels, tools to build and test the planes... they managed to double the speed three times!

And this was because the rules were so simple, it was about to create the fastest seaplane.

There were no more rules, nothing about how to draw, design, build and test the plane, it just had to be a seaplane, she had to float, she had to fly...

And that was it.

The Schneider Trophy might just be a Cup. But British designers learned a lot, and when they designed the Supermarine Spitfire, they had all these learnings in mind.

These were the good' ol days, but we need to have in mind, that our present days were the future for these men. And that the future we are building for tomorrow depends on the decisions we take today.

Nowadays everything comes with software, we have replaced the Steam that powered all industrial revolution with software that does things, everywhere. And this software was to be designed, developed, and somehow tested.

I am a Software Tester, and that´s what I do, I test the software my development team produces, I help them delivering the best quality in whatever we produce.

And if this wasn´t complex enough, there is a new ISO 29119 coming out with a set of rules about how my testing should be.

From what I have seen until today, and getting back to my story, they are trying to tell me how the seaplane should be designed, how it should be built, and how it should be tested, they are asking me to build a biplane, just because at some point, all planes were biplanes and that was how planes should be.

They are suggesting me how to plan, how to document and how my process should be, and I don´t want that. In the last 20 years, Agile Development and Context Driven Testing are changing how software is being developed and tested, and this ISO is for no use in these contexts, moving us back to the waterfall days, where every discovery should be planned in advance.

As a Professional Tester, I don´t agree with such a rule, I don´t want to be forced in the future to follow such guidelines, I want to be able to experiment, to learn, to defy whatever preconceived rule might come in our way to produce the best software we can do.

I want to understand where the problems are, and how to get them fixed, I don´t want to work with a set of solutions that a board of consultants and academic teachers defined as all I needed to know, No thanks.

If you are a Developer, I'm pretty sure you don´t want it either. And if you are not a Tester nor a Developer, the bad news is that it affects you too, because you will be the final user of whatever we manage to deliver.

There is a nice page to follow the debate about the ISO at the Ministry of Testing.
And if you feel like, you can sign the petition to Stop 21991 as I have done.

Thank you.

Short list of books to read, if you want to know about software testing.

My short list about books related to Software Testing:

 

• How to Break Software (Amazon). In this book James Whittaker go into the basic actions of software testing and boundary analisis. Once you get the idea about how you should test one single field, you might like to read...
• Explore it! (Pragmatic). Where Elisabeth Hendrickson will explain how you can explore your software, be it a desktop application, a web or a API. Once you know how to explore and test, you might want to understand why this is important, so...
• Perfect Software and other illusions about Testing (Amazon) By Jerry Weinberg can help you understand the relationship of testers, developers and the rest of the world.
• And the closest book to a Bible we have in Software Testing: Lessons learned in software testing.

And there is more...

• If you want to go Agile: Agile Testing and More Agile Testing will help you understand the Agile Context.
• If you want to grow big: How to reduce cost of software testing.
• If you want to grow nice: Beautiful Testing.
• If you want to have fun while testing: Cartoon Tester.

I am missing some others, but otherwise this would not be a short list.

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.