The trip to Brighton

I just went to Brighton to meet Michael Bolton and his one day Rapid Software Testing for Managers training course, Let me tell you how this happened.

Back in August I was thinking about getting to Eurostar, you know, Europe's most important testing conference, this years programme is impressive, but important and expensive have quite similar meanings.

As I have a budget with a limit, I found out that the whole conference was quite too much for me, but maybe I could go to the tutorials, after all, James Bach was going to talk about Rapid Test Management And Pradeep Soundararajan was going to talk about Context Driven Mind Mapping, exciting tutorials, just a bit important for me.

But then I had to get there, and here I found another learning, that the world is divided in levels of travel expenses.
The first level, is where I can get by train or by a single low cost air ticket, so, since I live in Valencia (Spain), cities like Barcelona, Madrid, Malta, London, Paris… are places that are easy to get there.
Next level is where I need to get two low cost air tickets, and flying to Gothemburg was on the next lever, then book some hotel room and plan some cash for expenses as lunch and dinner… It could not be done.

Then Rosie published at The Ministry a training course, in Brighton, with Michael Bolton about Rapid Software Testing for Managers in one day for 200 GBP, it sounded quite similar to the tutorial James Bach was going to give, it might not be the same, but it was affordable, so there I went.

At the end, for the price of a low cost flight and a comfy hotel room for two nights, I got the chance to meet Michael and to know Rosie, Richard, Stephen and many other testers that got to the same place. 

We talked about testing, bugs, estimations, relationships, the reality steamroller, estimations, management, lack of management, lazy developers, estimations again, testers education, hiring testers, broken systems that works for somebody, Jerry Weinberg, more about estimations, the three reasons you need to justify bullshit, the testing vortex, how to write test reports, what a testing career looks like… and as it happens, things that were talked made me think about how I am delivering my work and how I can do better.

After the training we went to a pub for some beers, and after some talk and more beers I consider that it was good enough for me and headed back to the Hotel.

I see bugs...

I think the way to get out of Zombieland is by letting you curiosity grow and getting trained, and while some trainings are too important to get there, this does not mean that there is no way, people like Rosie are organizing small events like this one, and I feel proud of being able to join and support such initiatives.

Now I am thinking in a way to meet Pradeep... So, what's your plan?

Tester in the kitchen

So, it happens that the Software Testing Club is offering you a free ticket to Eurostar. All you need to do is publish a selfie foto and send the link to the STC, and then wait for things to happen.

This is my chance to get the price.

This is my in my nightly workplace, during the day we call it kitchen, but since we have 3 small kids around, the quietness that we enjoy once they are asleep is priceless, so this spot is perfect to not wake someone up.

Also, the fridge is really close!

18 Sep. Small update: The pic got it´s way and it is one of the chosen for the final run at ministry of testing ... So much fun!

17 Oct. Small update: Michael Herrman finally got the ticket, congratulations man, have a fun time and write a proper blog post :)

Family (test) trip to Konstanz.

This summer we hit the road to do some test driving, here is the story about how it went and how it looked like from my testers perspective.

Understand your mission.
I was born in Denmark and spent there my early childhood, because of this, one year of these we want to do a long travel to Denmark in order to show the kids the places where I grew up, but since that is a 2500km trip we liked the idea about doing some test first, So we decided to do a 2/3 scale trip and visit the city of Konstanz in Germany.

Success Criteria.
All 5 family members must return home, at the same time and without any injury.
The car must also make it back home.
The travel expenses had to fit in the budget.
We should all have a good time together.
We should reach our destination.
We should get home at the expected date.
Note that the three first are fixed conditions easy to verify, while the last three are optionals or subjective items, nice to haves but not a requirement.

Plan before you test.
Before we depart, we had a lot of things we should take care of, as checking car stuff, having the needed documentation, hotel reservations... so I did a mindmap where I could update the different items as long as they where completed.

Check your tools.
I updated the GPS map, wrote down the trip on a handy device, downloaded some country music, checked the tire levels (also the spare tire), got a travel fridge, enough water for half way, some books for the kids to read.

Test early.
We planned about starting the trip Saturday morning, but as the previous Friday we had everything packed up, we decided to trade a evening in Valencia for a visit to Avignon. So we booked a cheap hotel in Barcelona and started our journey as soon as we could.

Know your stakeholders.
Because this trip was a family thing, we decided that every day we would see something nice for adults and something fun for the kids, so we went to museums and parks, at least one per day, and by doing this, we all got a nice experience out from the trip.

Change your plan if you feel like.
Once we arrived, it turned out that the information about places to visit that I found on the internet was not exactly the same that we found at the tourist info at Konstanz train station, so we decided to change some items, and we did not go to the Fussen Castle, but we went to the Dornier Museum instead, we also visited Kreuzlingen even that it was not on our initial plans, but the info lady told us that the park over there would be something for the kids to see... and man, she was right, they know how to maintain public parks for small children in Switzerland, and now I know this.
Also, our visit to the Rheinfall turned out to be shorter than expected, as the kids interest on a huge waterfall quickly dropped after 10 min of watching a river, so we spent a longer evening at the Allensback park.

At the end, we visited Avignon, Konstanz, Friedrichshafen, Rheinfall, Kreuzlingen and the Bondesee arounds, we drove about 2300km and we got back home the next Friday, safe and sound and thinking on our next travel.

What have we learnt out from this.
You got to choose how to travel, as you choose how to test.
Either you make a lot of kilometres or you visit some place, but you can't do both on the same day. For us, if we drove 400km then we still had time to spend the evening and see some place, but if we planned 700km for the day, then we would just have time for a bath and then dinner and then bedtime.

It comes with a price.
Whenever you decide to travel, you need some time and some budget to spend, once you got both, you can decide if you want to take a plane, a train, or drive your own car. In some way, when we automate stuff it becomes like flying, where we go from point A to B but we don't really know much about what is in between, but if we want to arrive to somewhere in a short amount of time, then manually driving do not seem to be the best way.

Is it worth?
Yes, both travelling and testing gives you a insight about how is the world around and how does the application work, and if you think it might be expensive, well, then think about the costs of not doing it.

The test ride.

Yesterday we went to our local Honda bike dealer. They where doing what they call 'Honda Day' and it is a opportunity for anyone to take a close look to new bikes and to do a test ride.

This year, they where so nice to let me a brand new CBR500R. I was not able to take a picture, but the bike looks something like this:

Sweet dreams are made of this.

My wife and I we went out for a ride outside the city. The bike feels great, it is very easy to drive, and the brakes and the frame are just outstanding. For more info about the bike, here is a professional review.

After the ride, we asked about price and loan conditions, and it happens that you might get a 24month loan at 0%, not bad at all.

So, we got a nice bike, some good loan conditions and... are we going to buy one?

Well, as everything in live, it depends on the context...

It happens that we already got a bike, a trustworthy Vespa PX200. We use this bike for daily commute and from time to time, when we feel like going for a ride, we rent a second unit at a local shop so we both got some throttle to twist.
So by now, the Vespa is doing quite fine and we don't really need this new bike, even if it rides quite well.

 As a tester, I would say that the new Honda is ready to go to production, I would say that it is more powerful, safer ro ride and has a better mpg ratio than my old Vespa.

But still, I don't run a business, but I do run a family, so as a stakeholder I would say that we don't want to spend the cost of this new feature.

Remember two things here.
1. Priorities of a business are part of the context too. And use to change in time. Be aware when testing whatever feature about the context the business is running in,  and if priorities ever change, remember to re-test if needed with this change in mind, because your old testing criteria might be outdated.
2. Every new feature comes with a cost. Whatever new stuff it does, is by using resources from somewhere, be it cash from the bank, or access to database or page loading speed. Before running a new feature to production, after testing it works, make sure you are aware about the cost of the feature.

Sometimes it takes a chupito

Sometimes a bug goes to production, and it happened to us last week. When this happens, it use to be a chain of events, of situations, that happens at the same time and allow this particular bug to reach production. As there is always a human interaction, there is also somebody to blame. Here is how we handle blame inside our team.

I was testing a new feature in my testing environment and I noticed that a button of one of the queues was not working at all, I just clicked and nothing happened. No action, no error, no console message... nothing.

My capybara tests where also having trouble with the button, they could not find it and where failing. As this button was not related to the feature I was testing I decided to look at it later.

Once I got some time to look at it, I checked that there were three features merged on this environment, so it should be one of them containing the bug. I did a full deploy of the first story, this is, the master branch and the first feature deployed on the environment, and noticed that the button was not working.

I went to the developers and explained what I had just done. 'No way, this feature and the failing button are not related' he said.

So I deployed the second story and the button was still not working, so the bug was not on any feature, it was on the master branch and we did deploy one day ago to prod.

The second thing I thought was "How did this happen at all? " and just then, a operator came to us to tell that a button was not working on a queue.

So, there was a bug in production, because a javascript code.
And we don't do unit tests for all our javascript code, we should, but we don't.
Because this was a small release, I did not run all my integration tests, I just ran the smoke tests because we wanted to deploy fast and those should be enough. If I should have ran the complete suite I would have caught this bug.

So, as shit happens from time to time, we got a protocol for fixing things.

First, both developer and tester take a chupito, not too strong, 'cos we still need to fix things, but as a shared act of responsibility acceptance, it is our debt to the product and the team, and we pay our debts. (Skol!)
By doing this, we talk with the team about what just happened, how is the fix and how to avoid this happening again.

Then the dev fixed the JS thing and I changed the smoke suite, so a bug like this won't get his way out to prod next time.

For a middle term solution, it is a need we have to create unit tests in JS, and out from integration tests. We also saw this talk from +Amy Phillips and she gave us some light about the way to follow. Not that we already had an idea, but her talk has helped us putting priorities in place. To fasten the deploy process and decouple the testing and the deploying process are going to be our next goals.

Back to the blame, the chupito thing is our way to celebrate our failure, to avoid blame wars and pinpointing anybody because a bug made it to production. We just isolate, celebrate, fix and deploy every bug we find. Some make the way faster, others take some time, but we don't have a separate bug count from our pending features. As +Antony Marcano pointed out, a bug tracking system is nothing but a hidden backlog.

The Deploy

As you might know, I am the tester guy at peerTransfer. I find myself emdebbed into the developers team. This time I want to tell a story about a deploy, a nice one, a big one.

We use to create short stories about what needs to be done, the usual as a Biker riding my bike, I want my bike to go faster so I can reach my destination in less time.

We create a github issue with such a story, and to give visibility to all the company we use a Kanban board to write this stories down. Then we start a conversation about details as do we mean faster on straight line or around corners, are we still going to stop on the traffic lights, drive by night when there is less traffic... details that help us having context about what is the problem and how we might solve it.

This time, we needed a deep refactor of the operations queues. Our company backend has basically three steps, we collect money from our users, we move it from account to account and we pay to our schools. This is our business, this is what we do.

The refactor was about taking out logic out from the daily operations and create a more complex setup, so to automatize the daily operations, looking for decrease the effort we do when performing such operations. As a biker, I want this bike to go faster.

It soon came out that this story could not be split on several releases, as we needed to do core changes on the site, whenever we would deploy we needed to do it all at once, or at least a big deal at the first time. As a biker, I need to use my bike on my daily commute.

So we created a attack team, this is, a team with people from developer, operations and product teams, this commando hold the needed meetings to define what exactly we were about to deploy, and then, the three devs defined a list of tasks that needed to be done and started coding.

Whenever each one of the developers found some trouble, they paired with another to solve the issue and if any doubt came out, a chat room with the rest of the attack team helped to clarify how things where supposed to work. We built a new engine in the garage, without pulling nothing out from the bike.

At some point, the development branch was ready to be deployed so we reserved a testing environment to use it for testing. We deployed the issue and we checked that the happy path was working as expected. Using a beer can as fuel tank, we started the engine to check how well it was doing.

Time to test. We decided to split effort, so while I was updating the automated test suite with the new features, the ops team member was testing that it was working as expected, for doing this, he created a set of tests with examples of usage and checked that all the results where the expected ones.

We found some bugs that where solved and deployed in no time, and we also found some improvements that would be nice to have on next iterations. After all, this is the first one and for a limited amount of time it is going to be okay to have some rudimentary controls... as long as we build them later. Somehow new stories are quite a valid result of a testing session.

Then we met again. I explained what I did automate, he explained what he had tested, what was working. We came out with new questions, we found that another test case would be nice to automate, and then we had a conversation about how the feature could break. we designed new tests to learn about what would happen is things where badly configured or what could go wrong. We found out that the pass to production would be a tricky question. We needed to prepare the bike before we changed engine. We decided the steps to take.

Our new tests found new bugs, so while we automated the last test, the bugs where solved, deployed and tested.

At that point the build was green and we had the definitive +1 from the operations team.

It was time to deploy. We pushed the button and waited the time to run the scripts, we deployed to staging environment... And the deploy failed.

Well, the deploy went well, but we needed to run a rake task to set things up and this was failing due to some conflicts on the last merge.

The unit tests where all green but the integration tests failed because of the failure on the deploy. Then we looked for the cause, fixed it and deployed again to staging.

This time we had success on the deploy. But the time frame to deploy to production was over, and as next day was Friday, and we don't deploy on Friday.

Uh, well... at least we have a rule that says that we don't deploy on Fridays.

This rule, is a agreement the team made at some point in the past. They all agreed that it was better not to deploy on Fridays, to avoid trouble during the weekend. But time has passed since, and now we have a more automatized deploy process, with better tests and better monitoring. So now we are more confident about the deploying process. More confident about jumping our own rules.

So we deployed on Friday morning, what the hell, this is why we test, we check and we monitor!

And the deploy went fine! Operators started using this feature and now they need less time to perform the same actiona, we found a couple of minor bugs once in production, and none critical enough to justify the time we should have needed to catch them before release.

We also sent an email to all the company explaining the new feature, because we like to communicate when we manage to deploy a big story like this one. We like to tell that our bike runs smooth and faster now!

As a tester, I took a look to the requirements, I automated some smoke tests, I helped designing and performing tests, I looked for the deploy process asking when and how we should deploy without causing damage. All that is testing, all that has a result in the quality of the work that we deliver.

We did a nice work, we did deliver a nice feature called #482, it's time to celebrate!

Credits: 
I found the pic of the Vespa here
The idea of the bike analogy is from this book
The other pics are from our peertransfer office.
The team I work with is a great team!

Out of the loop

For two weeks I been on vacations, quite out of the loop.

And it has been great! Kids decided to grow up. Aksel started walking by his own, Karen is a lady who can dress up by herself and Erik has found out that he can read, and that superpower can be used anytime anywhere!

I got time for taking coffee with old friends and for taking long walks, I think I managed to complete all the stuff I wanted that was not related with a computer :) how great is that!

We also went out for a ride, you know, you are not a biker if you don't ride... just as you are not a tester if you're not testing.

This year 2012 has been awesome. In may I went to London to do the RST training with Michael Bolton and also I was lucky enough to meet Tony Bruce on the London Tester Gathering. On october I went to the Barcelona Testing Open Session where I fired myself as a speaker. I am also being accepted as student on the Miagi-do, we'll see how that goes.
Working as fellow tester in Peertransfer has been a great oportunity to learn a lot of things, just to know that there is so much more to know out there. 

Plans for 2013 also looks great. We are setting up the Valencia Tester Gathering with a little help of many friends. Also the Let's test and Eurostar conferences are on my radar for this year... we'll see how this goes.

So, I wish you a happy 2013, it's good to be back.