As a tester, did you ever go into a conversation with the upper level management? did it go well?
In this great talk, Keith Klain will walk us through his experience in this matter. Please check the video at The Dojo.
Here is a mindmap about the talk:
Saturday, 16 January 2016
Finding bugs before writing code – Sigge Birgisson at TestBashNY
As a tester, would you like to be involved earlier in the projects?
If such would happen, would you know what to do?
Here is where I got hooked to this talk. Sigge will walk us to the process they follow in Atlassian to test the issues before they start writing the code.
You can check the video at The Dojo.
And if you already done that, here is a mindmap about the talk.
Monday, 2 November 2015
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.
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.
Friday, 14 August 2015
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.
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.
Friday, 19 June 2015
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! |
Sunday, 7 June 2015
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:
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.
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.
Friday, 10 April 2015
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.
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.
Subscribe to:
Posts (Atom)
Letting it go.
I dropped my Twitter account. And somehow, it did not make sense to write a tweet about it. Many years ago, when I was riding by bike as cou...
-
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...
-
Yesterday was my last day in Flywire. How does it feel to be laid off after 8 years working in the same company, the same project, along w...
-
When I read the Context Driven Principles, and I think in the testing I do, this is how I interpret them: The value of any practice depend...












