List of 5 Books about Testing from James Bach

Last month I got the chance to meet James Bach in a Rapid Software Testing training in Newcastle UK.

This training feels like catching grapes in a sandstorm as Greg said, because a lot of information is being exposed, and you are going to catch a fragment of it.

So I took notes :)

One of the conversations that happened was on books about testing. James said that some were misleading people to don't understand what testing was about.

So I asked James for a list of 5 books he though were pointing in the right direction:

An introduction to General Systems Thinking, by Jerry Weinberg.

Tacit and Explicit knowledge, by Harry Collins.

A Practitioners Guide to Software Test Design, by Lee Copeland*

Exploring Requirements, by Jerry Weinberg.

Perfect Software (And other illusions about testing), by Jerry Weinberg.

Six Thinking Hats, by Edward de Bono.

*In my notes I got a book called Software Test Techniques by Lee Copeland, but the only book I managed to find is this one.
** Yeah, those are not 5 books.

Sometimes you have to let things go. (Bye ISTQB)

This past two weeks we have been on a family roadtrip, all the way from Valencia to London.

When you are driving, you get into a mental flow, where your ideas get connected in strange ways, so the thing went like this...

At some point, while I was driving down some nice highway in France, it started to rain heavily, so much I could barely see the car that was in front of me.
But the lights of the car was the only thing I could actually see, so I decided to stay there, at a safe distance from the car, and follow those red lights until the weather would get better.
Given the context I was in, it seemed the best option.

Then, when the storm stopped, when I was able to drive by my own, I mentally thanked this unknown driver for helping me this part of the trip, and for not falling down any bridge while I was blindly following him.

That night, once in the Hotel, I checked quickly the email, and saw this rutinary email from linkedIn telling me that somebody is seeing my profile. This happens from time to time, and I usually don't pay attention to this message.

But wait, what if they are in a middle of a storm, looking for somebody to follow, what is they are looking for advice, what if they see that I have the ISTQB certificate.

They might think it was worth, when it wasn't.

I paid too much money, for a bad training and a useless certificate. Yes, I learnt something, yes, I met other people...

But I have learnt a lot more in other trainings and conferences.
And I have met a great community in those events.

So it's time to let it go, just in case somebody chooses to follow me for a short time, at least it won't be in that wrong direction.

And since ISTQB won't return any money as it happens to be a lifetime** certificate, at least I am deleting that line from my LinkedIn profile.

*The picture is not mine, I found it in this blog.
**For this lifetime, I am the son of my father, and I am the father of my sons, and no ISTQB certification shall compete with that.

Nordic Testing Days 2015

Last month I went all the way up to Tallinn in Estonia to attend the 2015 Nordic Testing Days Conference. 

The trip was nice, but it took me 12 hours to get from door to door. Tallinn happens to be (almost) at the other end of Europe.

I went there for two reasons:

First was to meet with other testers, and this went just fine! Even that the staying was short I managed to get nice conversations about testing related stuff that is actually keeping me busy, and also about future talks I would like to deliver.

The attendants at the conference seemed to gather in three groups, some spoke Estonian, some did Russian, and some others had English as common language, but whenever I tried to start a conversation in English, I found that people in general was open and willing to follow.

Another thing I noticed about the delegates is how young they were, (and no, it is not me getting older!, I been in other conferences and this one is a bit different, these young people are going to rock hard the testing scene in some years, just wait and see.)

The other reason was that I was going to give a talk. This was my very second time I gave a speech (yes, I count my 99 seconds talk at TestBash as the first one).

And how did that go? Uh, I have mixed feelings...

It was cool, because I managed to submit a proposal, it got accepted, and I made it to the stage with my story to tell, you can check my slides here.

It was not cool because I need to get better on this if I want to do it right.

If testing is something you perform, giving a speech in English, well, that IS a performance, and I got a lot to improve there.

I found out that my level is so low, that improvising won’t just make it. It happens that if I want to perform a talk in English at a similar level that if I do it in Spanish, I need to practice, a lot.

I need a good story, or at least, a better way to tell my story, just as a rock star has good songs to perform once he is up on the stage. And then he knows how to do the performance.

Rob Sabourin gave a wonderful talk the day before, almost with tears in his eyes. Rob Lambert also gave a great talk about Why remaining relevant is important. If I want to get there, boy, I have a long way to go.

But that way is going to be walked one step at the time, so I’m terribly grateful for this chance to the Conference and to everybody involved, Guna, Helena, Rudolf and Grete among others, thank you, You all rock!

Thank you!

That Finnish Dude

I work a lot with mindmaps, they have become my basic memory repository, so when I need to remember some logic or how some artifact is expected to work, I go to my existing list of mindmaps and search there, because it is probable that I wrote one at some point, when my understanding of that artefact was recent and clear.

And it's because somehow I have learnt how to use them, and I learnt that out from somebody else.

When I joined peerTransfer, as I was going to be the only tester, I found myself with a wide open space to define how the testing will be happening, and soon I decided to try using mindmaps.

I allready knew about them, and remembered to have readen a blog post about how to use them.

But at the time I first saw that post, I didn't really have the need of learning that. I was working in my previous company, and was not really aware about the future changes that were going to happen.

Four months later, I had joined peerTransfer and now I really wanted to read that post again, but I could not find the link.

Diving in Google can be difficult if you don't know what you are looking for, because you can not remember the author, nor the blog title, or where I got the link from.

All I knew is that the post was about mindmaps, and that the writer called himself "The Finnish Dude" (how many can they be?)

At some point, I found the post:
Managing Heuristic Exploratory Testing Based on MindMap

That post helped me a lot to understand how to work with mindmaps, and the funny thing is that last week, I flew all the way to Estonia, to attend the Nordic Testing Days and to deliver a talk about our kanban board in peerTransfer, and when I sat down at the dinner table, a guy joined our table, and it went like this:
- "Hello, I am Jokin Aspiazu, nice to meet you!"
- "Hello, I'm Pekka Marjamäki, nice to meet you."
- "... Wait, aren't you that Finnish dude?"
- "Uhh, yes?"
- "You wrote a post 3 years ago about how to use mindmaps, that post really helped me a lot, thank you!"
(Big smile) - "Wow, thank you! you just made my day!"

 At the end of the day, it went something like this:

Moomin, Pekka, Santhosh, Guna & me

When you know about something, write it down, and share it.

You don't know who it might help, if you want a living example, please check the mindmap lists at test insane.

Consider your time as a training resource (Gracias Paco!)

One of the conversations I had with my friend Tomislav when we went to the Copenhagen Context Conference was about our careers in testing.

Basically, we are doing well. We are both working where we want to be, with exciting projects ahead and a lot of things to do and learn.

We are two lucky guys, and we wondered where did it all start.

And it started with a manager.

This was back in 2010, a bit before testing was supposed to die, we were working in a software development shop, doing waterfall development and calling it agile.

But one of the managers was curious about finding ways to improve the quality in the process, and getting training for his employees.

He heard about the google 80/20 policy, you know, if you work for me you have to work on what I tell you on the 80% of the time, and I will let you do whatever you want on the resting 20%.

So he decided to try that out on a certain scale. It was going to be 90/10, and you could choose between read books, do online trainings at microsoft.com (this was the pre coursera age) or read whitelisted blogs (yes, the internet was blacklisted, and nobody has mobile internet access in those days).

And he liked to read books, he used to read a lot of them, so we soon found out that we could use this time for reading books as well.

We would ask for any book related to software testing and get it.
We would have one hour every day to read our books.
And once we finished them, he would spend time talking about the book, what it was about, and how could we apply those ideas.

He gave us time, time to read, to think and to share about what we were reading.

And this was great, we managed to read a lot of books, we got used to read books about software testing,  I didn't realize that until I found myself buying and reading books way after I left the company.

So, going back to my 99 seconds talk at Testbash 2015, the three points I wanted to share:

- Conferences are a great place to learn about software testing. Ask for budget to get to conferences.

- If asking for budget is not an option, ask for time. Time is a valuable resource, use it wisely.

- Be thankful for what you get.

Muchas gracias Paco, te estoy muy agradecido por el tiempo que me dedicaste cuando trabajamos juntos.

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.