Book Review: Stranger to the Ground, by Richard Bach.

This book is a must have for any aviation geek, it tells the story of a Pilot, who does a flight in a F-84F Thunderstreak from South England to Central France, in a stormy night somewhere in the '60s.

The story is written with such detail, that you get to know all the sounds, noises, procedures and details a Pilot goes through when flying a simple mission.

Before he climbs to the plane, he get's a report of the status of the plane, with known issues, just as a automated test suite tells you that all CI tests are green, the Developers have reviewed the code and that the issue is ready to deploy.

Then he starts the engine of the plane (designed to start with a explosion!) and tells the Ground Crew to detach the airplane from the APU that brought it to life, just as a Tester deploys a the new feature into a testing environment, in order to perform the testing.

He flights following his flight plan, from Southern England, to Central France, but with a planned deviation from the straight line in order to avoid the Massif Central and the mountains that stand proud over 6000 feet hight, just as a tester knows what the feature to test is about, and what kind of actions he is going to perform in order to learn from the resulting observations and decide if something is not as expected.

In the middle of the night, he sees signs of a thunderstorm, evaluates the known risks, and decide what to do next, asking for weather reports to those airports that are in range of his radio so he can evaluate the situation and take decisions, Just as a Tester can ask to Developers or Product Managers, or whoever might provide useful information, for a deeper understanding of what he is observing, so the ones that have to take decisions have the best available information.

While he is flying, he recalls the days he was in the flight academy, and he thinks in how easy it is to fly a jet fighter... even his wife could fly the plane, and drop an atomic bomb, as soon as she learns how to do it. Does it sound familiar to the anyone can test we use to talk about?

At some point, he flies straight into a thunderstorm... and you know what? I am not able to come with a single example of a Tester running into such a situation. This is why I admire Pilots, because they know how to fly, and because of this flying they might get into situations that I will never have to face as a Software Tester.

The closest I have been to the experiences described in this book must have been when I was in my twenties and my only vehicle was my motorcycle. I have driven 700km in a single dark night, with the only guidance of a front-light, and the company of the green backlit from the speed & rev gauges. I have gone through snow storms in Spain, heavy rain in the north of France, I have seen a truck tire exploding just 10 meters in front of me, and I got lucky a few more times. But I never went into a thunderstorm flying a small jet fighter.

At the end of his story, he lands his plane following the procedure for a blind landing, and delivers the canvas bag he was carrying because this was his mission, just as a Tester writes the report of what he has tested, how does he know the results were the expected ones, and how did the testing go, if he found any issues that slowed down his testing that could be interesting to share.

Did I say this book was for plane geeks? Well, maybe it could be a book for Software Testers after all.
Give it a try, and tell me what you think.

New times ahead! ( Yay!, we are hiring! )

If you have been following this blog, you already know that I am the fellow tester in the peerTransfer development team.

Well, the thing is that we got some changes in the company and now we are thinking big, bigger than ever.

We have grown the teams, splitted them into squads, and we keep growing, so the time has come to get other fellow testers on board.

Working as a tester on a Agile team in a Startup like peerTransfer is a peculiar job, but it is being the ride of our lives.

Please check our Offer, and if you feel like joining us in sunny Valencia (Spain), please let us know.

Drive like you were testing

The analogy about testing being as touring some new place has been quite used. There are even books trying to coin that all Exploratory Testing can be condensed in a set of eight tours performed by some profile user.

I'm going to try the inverse, I'm going to tell how it went out once we were travelling, and how I took some decisions based on my testing experience.

We were on a family car trip, from Valencia to Paris in several days, and this day we were going from Montpelier to Vichy, we had all day to cover this distance, we were on vacations so we had no hurry at all.

We already passed the magnificent bridge of Millau, and it was about time to stop for lunch. I was sitting at the wheel and even that we had enough fuel for 150 kilometres, I decided that we would stop for lunch near a Gas station and tank up.

The traffic wasn't bad in our direction, it was not clear enough to rely on the cruise control, but we were almost doing 120 km/h.
But because it was the first week of August, half Europe was driving down south using the other direction of the meridienne highway. It was a true french Bouchon going on there.

I decided to stop at the 'Aire de Service Lafayette - Lorlanges' it was 40 km ahead, and when doing 120 km/h that means 20 min arrival time, so it wasn't bad at all.

We got to the exit, and there was a roundabout to enter to the gas station.

But I noticed that there were cars parked in the roundabout, my thinking was:"Why would anyone want to park in a roundabout, this is as far as you can get from the gas station...
Because there is no other place to park, because this gas station services to both directions of the highway, and there is no more space than this". So I kept turning in the roundabout, without entering to the gas station.
-"We are not stopping here." I said.
- "Why is that?"
- "Because if the parking lot is overflowing up to the roundabout, imagine how the cafeteria or the toilettes might be."

I exited the next road on the roundabout, and followed it for 2 kilometers, in my hope of finding a second gas station, but didn't find anything, only beautiful forests.

Then I stopped on the sideroad and went to the GPS. Exploring narrow roads is fun, but now I do want to find a Gas Station.
-"Oh, you have one just two kilometers behind you." The GPS told me, he is a clever guy, but I know something that he does not.
-"You know, I really want another gas station, what are my choices?"
-"Drive this road and turn left in 3km"
-"Let's try that out"

And at the end of the proposed path, we found a small and clean place, with Burgers, Nuggets, Kebap and French fries for lunch, given that we didn't need anything more, this gas station on Road N102 between Lempdes-sur-Allagnon and Vergongheon was a perfect place for us.

When you are driving, you do have a mission, and a plan, but if your plan is too tight, every discovery you might do once you are on the road is going to impact your initial plan.

When you are testing, you do have a mission as well, but you need to be aware of small unexpected happenings that could pass unperceived, like a badly parked car at the entrance of a gas station, and decide as you go.

Maybe your test plan was good when you made it, but be aware that you made it at the point when you didn't have much information about what you were really going to find, so once you get new information that makes you question your initial plan, you better be able to take decisions about where to go next.

Workshop about Specifications and Testing.

At the end of February we got to the Copenhagen Context Conference, I would like to write some posts about how it went.

Workshop about Specifications and Testing.

The first day of the conference we went to a tutorial by James Bach & Pradeep Soundararajan.
Jon Bach also showed up, since he was just arriving and hadn't seen his brother for a while.

Since the ideas that we talked about are still thundering in my mind, I am going to use a story as backup.

This is a story about a Panda named Po, who would like to learn Kung-Fu.

It's also the story of Tai Lung, a cruel and skilled white tiger, who would like to be the Dragon Warrior. After all, he went through many years of hard training to get such title and he believes he deserves such right. Then there is Master Shifu, He did train Tai Lung 20 years ago, but he feel sad because his student went evil, and now he has to train Po.

In this tutorial we talked about specifications, about how they can get complex to write, because you need to find out the explicit and the implicit knowledge, and write it in a way that developers and testers will have the same understanding that you have.

Writing requirements is a discipline hard to master.

In order to experiment, we did three exercises, we tested three apps.
First getting the requirements first, and then the software.
Second getting requirements and software at the same time.
Lastly, getting the software first, test it and then get the requirements for it.

Po gets the title of being The Dragon Warrior almost by accident, and then, he starts to train and learn Kung-Fu, because having only the title won't be enough to defeat his enemy.
The action goes around an item called The Dragon Scroll, which contains the secret to become the true Dragon Warrior. 
Tai Lung will use violence to get the scroll and learn the secret, Po will train to become the Dragon Warrior and at one point Master Shifu will give him the Dragon Scroll.

What do you think was the best experience? well, if we follow the rule that says that you should have your test cases first, the first one should have been the most successful tested app.

But since testing is a performance, it happens that when you do not tie yourself to a script, you get freedom to experiment things, and since we are looking for unexpected behaviour at the app, those are not going to happen if we only execute the expected actions, and we found more and better bugs on the second and third exercises.

The point was, that when you review the specifications you can focus on:
- What are the obvious specifications, understand them and move on.
- What are the non obvious specifications, those are important, since the developers might have a different interpretation out of these.
- How are you going to test this feature. You need to think in what tools will you need to use, what understanding will you require to have.
- Do you understand each one of the phrases in the requirements? read them slowly, and focus in one phrase at the time, make questions and get answers.
- Focus on the critical information you don't want to forget when you will be testing, mindmaps are great for this.

Just, don't write test cases at this point, but prepare your learning, your testing ideas and your tools. You can create your testing cases once you got the software in front of you, once you are able to explore and learn, and question the software, instead of the specifications.

At the end, when Tai Lung finally takes the scroll, he gets disappointed and stunned when he discovers that it is blank. 
Po, tells him that it's okay, since he didn't get it the first time either. Tai Lung is still confused, so Po explains to him that "there is no secret ingredient; it's just you."

Users will use your software without test cases, so, what if I tell you that you don't need test cases to test your software, but you need to be a skilled tester to test it right.

There are some slides from James Bach about test cases you might want to check is you have done this far.

Day 0 at the Copenhagen Context Conference.

At the end of February we got to the Copenhagen Context Conference, I would like to write some posts about how it went.

Day Zero, The Gathering.

It happened to be a testers gathering the night before the conference started. So the people from Trustpilot invited us to listen to James Bach performing a talk about Building Testing Skills and Reputation. 

James explained how you can get Testing skill and reputation, using his own history as example.

He told us that you first need to be a good tester, that you need to learn how to be a good tester. Be that understanding your technology, your mission in your team, testing techniques, communication skills... Anything that will do a better tester out of you. Check out his CAST slides about Testers self-education.

Once you start becoming a better tester, you want to be a known tester, because otherwise, the day you find yourself without a job, who do you think is going to call you if nobody knows you?

James encouraged us to start building our own contact network, so people would start knowing us.

My experience is that Tutorials, Training events and Conferences are a great place to know other people, but these costs money and time.

Writing a blog, following and commenting what others write does not costs money, but it takes time.
And if you don't want to spend money or time in your own education, well... good luck with you thing.

What you need to understand, is that there is a market out there, and...
There are zillions of unknown people doing software testing, if you are one more, what impact will it have.
There are 356,746 certified ISTBQ testers, and you could be the one who made 356,747 and what impact will it have...
There must be several hundred testers that went to the RST training sessions, I don't know the numbers, but I can tell you, that training did have a impact in my testing skills, so it's something you can try.
There is a list of top 114 testing blogs and this humble publication made it to #95, so you could start your own blog and see where your score is next year. You might not beat James Bach, but you could do better than I do.
There are about 20 testers that are going to give a lighting talk in this years Testbash, so, do you want to be known? Be brave! and tell your story.

You choose where to spend your time. You could get the training that everybody else gets, or you can learn skills that make you different. It's up to you, but imagine for one moment, that you have a skill you like, and that you get (really) good doing it, and that somebody is whiling to pay you for performing your well known skill... how would that be.

We had a wonderful evening listening to James, and it seemed that somebody in testpilot really knows how to host a gathering.

What can I say... I wish I would host such an event in our shop, with somebody like James giving a speech, but if I ever do, you have set the bar really hight.

Congratulations to all of you involved in the event, I had a great time.

PD, Trustpilot have open positions for QA Engineers. Given that the location is great (I been there) maybe you want to check their offer.

Copenhagen Context Conference 2015, How we got there...

So, My friend Tomislav and I got to the Copenhagen Context Conference, and since the short story has already been told at my twitter account, I'm writing down the long one here.



How did we get there...

Well, because we are lucky.

We are lucky that we started out testing career working with a manager that would get us as many books about testing as we asked, and let us some time to read them at office hours,  that was the spark that started all this. We learned that there is a testing community, formed by testers, trying to get better in what they do, to become true craftsman in software testing.

I was lucky enough to have lunch sitting next to Derk-Jan de Grood, at the Bilbao Test&QA Conference last year. We talked about getting a proposal for a talk, and he told me that a good idea is to tell something that happened to you, to tell your own experience in your work.

Then, once the Copenhagen Context Conference call for papers was done, and the programme got released, there happened to be a chance for getting one free ticket for the conference. You just had to submit a video explaining why you would like to go there. (Well, the topic was about getting Context Driven Testing further, but you know what I mean)

I had to give it a try, I would tell a story, the story of how I became a Software Tester, but I would not record it at my living room, that's too lame, I would record it outside, with a green background, that's always nice. And I would not record it alone, I want somebody else in the frame, so I'll ask my friend Tomislav to join me, after all, we become software testers the same day.

Then the night before, I realized that it would be waaay more fun, if instead of asking a place for me, I would ask a place for him at the conference. And I didn't tell him anything, so the surprise in his eyes when I come out with the idea was a true surprise recorded by the camera.

This was fun, really fun, and that's how Tomislav got his way to this conference.

For my side, I went to EuroStar conference in Dublin, and met Morten Hougaard there. He asked me how could he get me to his conference, and we agreed that I would be the conference Blogger. We had both seen the awesome work that Neil Studd had produced for the conference blog and we used this as a example of what we could try to do. One post per week, be it long or short and I would pay my way to the conference.

Cool, but now you have to publish something, so I decided to ask for help, as the conference is going to be about the people getting to it, I asked for help, I recorded a petition with my phone, and using that as example, I sent it to the people I knew were coming to the conference. The feedback was just fantastic.

Pradeep Soundararajan:

James Bach:

 
Graham Freeburn:

Huib Schoots & Richard Bradshaw: Video

With this, and a little help from my friends, I managed to publish as we agreed, and that's how I got my way to the conference.

So, basically, we went all that way to Copenhagen because we were lucky.

But I'm telling you something... For the next years edition, there is going to be a free slot for a  Blogger, and it could be you.

Just stay tuned to the http://copenhagencontext.com/ site and give it a try, make your own way to the Copenhagen Context 2016 Conference.