If I have seen further...

 ... it is by standing on the shoulders of giants. (Issac Newton)

I'm almost one year in peerTransfer, being the QA Engineer, and I like this company.
I was the first and only tester the dev team ever had, so we have spent many hours talking about what my role should be and what the team and the company is expecting from me.

This has been evolving as we found new needs. I been testing new features we have been rolling out,  and also reviewing the requirements of new stories, taking care of the automated test suite, estimating when needed, testing production setups... and having fun!

Last week the dev team faced a change in the code. Operations team needed to refactor their  process and we needed to make changes in the code to follow along.

But once we saw the requirements, we still had a feeling about... something was still missing. The requirements we're okay, but because the change was big, three devs and I went to a meeting room to try to find out how to roll out the change without impacting the operations flow.

After some debate, we started to suspect that the model we where following was not exactly the right one, we had some discrepancies about what we where asked for and what we allready knew about operations crew was doing.

... so we asked two of the operations guys to join us on the meeting. After a few questions to pinpoint our doubts, I made a simple question:

"Please, can you explain again what is the problem you have."

And there it was, the problem the ops team was clear, and now we understood better the mission of this change.

One of the devs came out with a fast workaround that helped mitigate the impact of the time we would need to perform the change, and by doing so we where buying some time to develop the full feature.

After this meeting, we talked to the product team, to help getting the new requirements and putting the needed story on the kanban board, and start working on the solution.

This meeting was not scheduled. The time we spent on it was not measured in order to keep track about how much time each of us spend at the end of the month in meetings, we did not have a previous plan for the discovery, there were no managers managing the meeting.

We where just a bunch of professionals trying our best to get a solution...

and we did it, or at least, we came out with a plan, and the willingness to try our best.

you see, working with these people make me proud. It feels nice when you are standing on the shoulder of giants and you can see further.

How to do a conference.

This month I will be attending two events. the Barcelona Testing Open Day and the VLC Testing. So while I'm riding the train to the first on them, and given the effort of attending to them, here goes the list of the things that you should do when attending to any testing event.

First of all, this list is not mine, is Matt Heussers, so I'm just writing it down here for my pleasure of reviewing the points.

Find the original here. http://www.softwaretestpro.com/Item/5689/

Before the conference:
Read the brochure.
Pick up a 'vibe'.

Find a problem the conference might solve.
Attend with the intention of learning a solution.

During the conference:
Get the information you need
Conferences are for conferring, don't forget that.
Focus on your mission, not in the conference agenda.

On the ride back home:
pick three things you should do different based on what you have learned at the conference

Think about it!

One piece at a time

Last winter I bought a LEGO airplane for my kid. I had the box waiting for a rainy Sunday evening, and when that happened, we spent the evening putting pieces together. But as winter was gone, the pieces ended up in a box, with many others, and the instruction sheet was also gone for good.

But somehow, the pieces remained in the box, and this weekend my kid and I talked about building that plane again.

So we downloaded the instructions from the LEGO site and today we where supposed to build it up again.

Once I got back from the office, we opened the laptop with the instructions, we searched in the box for some pieces and there we went...

But we had not all the time of the world, so at some point I guess I started building the plane by myself, you know, just to get that done.

Then this 4 years old fellow told me... " Dad, I got an idea, how about you giving me the pieces so I can put them together. Just explain me how I have to do it, and I'll get it done."

Darn it! he was right, I knew how to build it, but it was not me who wanted to learn, that was him gently asking for it.

I passed what I had in my hands to him, and started searching in the box for the next pieces.

After some time, we managed to get all the pieces and build the plane. For this, we both where proud.

"Brrrmmmmmooarrrr"

Being a tester is a constant need to learn. Because there is so much you just don't know, that at least you should be learning something in order to become a better tester, and to get proud of the work you are able to deliver. And to learn, you need to practice, and you also need somebody to teach you, to help you think.

Rob "Social tester" Lambert has written a series of posts in his blog about testing a website. Each one of those articles are about something to take care, or something to know when you should be testing. And not enough of this, he has putted all the 36 pieces in a box, in a free ebook that you can download over here:

http://thesocialtester.co.uk/36-days-of-web-testing-the-ebook/

I was folowing the blog for some time, and I even opened some bugs with the advices found there, so all I can say is...

Thank you Rob for finding the pieces and passing them over.

From scrum to kanban

This morning James O'Sullivan wrote: "An agile team without the intense need to improve themselves at more than a superficial level is not an agile team."

And you know what? he is right, and I'm going to tell you a story.

When I started in peerTransfer, the team was doing scrum and I was the first tester they ever had. The stories where written in Pivotal and devs used to push to staging once every week. As every dev was developing in local, it made sense to put me to test in staging environment, along the product team, but this had some drawbacks.
- If a feature was finished on day one, it had to wait all the week to be released to staging, and since having developed features waiting for being tested is a form of waste, this was no good.
- For my point of view, I was always one week late, because I had to wait, when bugs started to arise, the devs had to go back to the code and try to patch whatever came out before it went to production.
- As I had one week to test, I needed to prioritize my testing, the more risky the feature, the sooner I had to start, and guess what, sometimes bugs came out because the features that had less priority had less time to be tested.
- If the pass to staging got delayed one day, for whatever reason, I had one day less for testing, because product team wanted to have the features rolled out to production on time.
- If one of the features went really bad, the whole release could be impacted because of this delay, adding pressure to the team.

We could do better.

So the devs implemented a board available on our site,  because the one with post-its was not suitable, being half of the team in Boston and the other half in Valencia. Then we moved the Pivotal stories that where ready to develop... and we deleted the rest of them as the future is yet to define!

Now, every story gets developed in a branch. this branch is deployed to a clone environment so I can test the feature. Then we merge and then we deploy.
I get stuff to test right out of the oven, and if I need some help, the devs are ready to pair test the features, because they still remember what they just done, and they still have not started with anything else.
We deploy several times every day, so if one feature needs more time, because of bad requirements or bugs being found, we still can roll out the small features or patches and keep testing the features that are giving us trouble.
We develop out own tool for the kanban board so we don't have to pay license for it, and we are able to develop whatever product or business people needs to keep working, we are a software developing team, and that is what we do!

As a tester, I must have some principles, some rules to follow. The ones that I know that make sense for me, are James Bach's Testers Commitments . And since we do kanban, we all do better, even I do.

and still, we all know we can do better :)

Hacknight at peerTransfer

One more ride

I'm a biker. Since I got my first scooter when I was 17, I always been riding. At first just for pleasure, then I spent some years working as a courier, then I started riding to do my daily commute to the office, and I still do.

My current bike is a Vespa PX200 that I bough new in 2001, it's not that I'm a MOD enthusiast, but it is easy to maintain and she never gave me any (bad) trouble all along the 120000km we been together.

Last week, my wife got her own bike driving license, and I'm proud of her. Proud because we started talking about her getting the license when we where not even married, and then came the three kids and all that life that happens along, and still, she managed to pass the tests, even if it took years to get it.

Given that the main purpose of having a bike at home is to commute to work, and that she finally got her license, it is quite clear that we will start sharing the Vespa on our daily routine.

But commute to work is using a bike... but not riding a bike, it is not the same.

Ride a bike, means that you are driving somewhere, or taking a drive, it means that you decide to go out the open road and be part of it for a while. That you will get cold, or wet, or sweaty, or whatever you might find... that you might feel alive, and you might enjoy the ride. So we needed a plan.

The plan was quite simple, get some time, bring the kids somewhere, rent another bike, and go for a ride...

For the time, the last day of the summer holiday was a perfect day, a bit cloudy, so the gear was comfortable, even in the Mediterranean august.

For the route, as you need to have some initial idea about where you want to go, we decided to follow this one. but just as starting point. If we changed our minds about the destination, it was going to be okay,  you know, you are never lost if you change your destination.

For the second bike, I found a Honda CBF 250 at a local store. The bike was in a pretty good shape, the back tire was asking for a change, and the neutral gear will not get in if the bike was stopped, but it had 22 bhp ready to run, and I did not need more for a ride.

The ride went just fine, I drove ahead for the most of the time, not that I was on any hurry, but I was confident about the way to follow, and at some point we stopped for a coffee and a picture.

So, this is us taking a ride, having fun, and taking it easy, as you do when you ride a Vespa.

And now, after we went back, summer is getting over, school is about to start,  I'm about to go back to work... well, I'm already thinking on, you know... one more ride!

Bug counts as (bad) quality indicator.

The dev team at my company has a Agile approach to software development. So my toughs here are about what is working and why and what not, but this always depends about the context.

 

I'm going to define a bug, as a story written in the bug tracking system, with reproduction steps and observed vs expected behavior.

When we open a bug, we are using is as an artifact, as a tool to communicate stuff to do, stuff to fix.

When a important issue is detected, it gets fixed as soon as possible, maybe without opening a bug. The priority is to get the expected result back again, as soon as possible. Sometimes, it is because a bug. but this also happens because of bad configuration or bad usage of the tool. We really don't care so much, because the priority is to get it fixed.

If the bug is not so important, for whatever reason, then we open a bug in the bug tracking system. We do this so we don't forget to fix it for the next release. This allows us to go faster, to take some risks so we are able to deliver the features as fast as possible, we measure the risks and we decide that if it is good enough to go, but some minor details are worth to get fixed, we ship it first and we fix things later. This is buying technical debt, but we consider that the release has higher priority than the fix off all known bugs, this is why we open bugs, but it is also how we get a new release every week.

So the exact amount of bugs opened is not a measure of quality, it is just a list of known things that are worth to fix but are not a threat to the business.

If we punish the dev team with bug counts, we are going to spend time on sterile discussions about if a bug is a bug, or a feature, or a bad usage, or plainly who to blame, and we are also going to tailor our results depending on what is being measured. But we are not going to get more quality this way.

If we use the bug tracking system to measure the quality of the team, we will be perverting the core function of a bug tracking system, this is, to solve the known bugs.

By doing this way, the team has a clear goal, it is to get the new features out, running and adding value to the business, making the user experience better than it is today, and not lowering the bug count.

These are not only my ideas, but I wanted to make a short writing. If you feel like reading more, please take a look at:

Cem Kaners writing , Joe Strazzeres writing, Michael Boltons wrtings here and here

What Carles Climent learnt when he left Aureka.

I might not be very good about writing things by myself, but from time to time, I find nice posts that I would like to share. Let me introduce you to Carles Climent and his blog. http://www.carlescliment.com/

I first met Carles Climent one day he was hosting a talk about quality in software development. The talk was in Aureka, the company he was working in. It was a nice talk, where we talked about testing and quality.

Carles had the initiative to host such a talk, so as I respect people with initiative, I started following his blog.

Last week he wrote about the lessons he has learned, he produced such a nice post that I'm about to share it with you.

About the process:
- Software developing is a human activity, so the trouble that a development team faces use to be human problems, and the solutions for those problems, should be on that field too
- Process is worth in the way they are considered a process. If you forget why, or you don't understand why the process is, this process could go against you.
- Agile methodologies are nothing without agile mindset
- Like a bullet, once you fire an email, there is no way back for it
- Everything is questionable

About people:
- Nobody can change other people. Not motivation, or opinion, or the way they work, no matter how many facts you put over the table, at the end, there are individuals who choose to change themselves.
- It is very easy to hurt other people's feelings, and that negative actions bring negative consequences
- It is better to say nothing that to just talk. It is better to silently make example with the things you do.
- Don't waste time with people that are turning your back, instead, give it to people that brings you a smile.

About Technique:
- TDD is the best finding in my career, at this point.
- Develop is like painting. You correct, you change brush, you look at details from close and to the big picture from far away. It is not a engineering activity, but a creative one.
- When you got no master available, books are quite good, but when we really learn is when we apply what we have readen on the team or on ourselves. Experimental method
and a team as a lab are the true masters.

About Excellence:
- Excellence is the path and not the destination. Every single new thing you learn, uncovers you a whole set of new things you stil don't know about, making you feel very small.
- Passion is a whole, you need to squeeze every moment and drink it's juice. Indolence, commodity, inactivity, are all waste.
- The line between passion and obsession is a thin one, so the key is to hold balance, at stay away from the fire when it is burning... and that is so hard.
- Talent gets thinner without effort. Effort gets into talent.

About the company:
- Everything that goes up, goes down again, and if it goes up quickly, it goes down in stall.
- Relationship between worker and company reached a higher level when there are trust, affection and mutual respect

About the future:
- I'm going to read more, go to the movies, run more kilometers, and have more free time than those last ears
- That it is time to build my own ship, that I'm unfolding the sails, and that there is no way back.

Only thing I can add to this post, is to wish you good luck.

because we have to!

This was 2003, mid-July and we where somewhere in La Mancha, in a town called Villarrobledo in a Heavy-Metal festival.
It was 5pm and the sun was blazing, with no shadow to hide, but there we where...

HammerFall just started playing, they came from Sweden, Joacim Cans rode a Harley Davidson across the stage and he started singing the first song, we all sang along, we all had fun.

When the song was over, Joacim looked at us, the people that had gathered at the festival to hear them sing, and he said:

"It is so hot out here! ... with all the sun... and all out leather jackets and dark clothes we wear"

we where silent, listening to him.

"But we have to! Yeah, because we are HEAVY METAL FANS!!!"

and we all shouted, we all did the sign of the horns, we all agree, we where a fellowship, we where heavy metal fans, and boy, we where sweating.


Now I work as a professional software tester since 2008, and I'm starting a blog in english, this one. I already co-write another one, but that is written in spanish, and even that I know some nice people that might read my posts if they where written in spanish, I think that as testers, our craftsmanship is jelled in english.

I wont tell why I should write a blog. Pradeep already has done that, and since he did it in english, I can read and understand what he is saying, this is why I'm writing one in english too. For me this is a challenge, and I think that wherever this road may lead me, I'll learn something new along the way.

This blog will be about software testing, and maybe about children, and maybe about motorcycles and music, and maybe about friends and experiences.

I just don't know yet, I just hope to get knowing along the way.

But I'm starting this blog, because I'm a software tester, because we have to!

Header test

Body test.

this is a font test
this is a font test
this is a font test
this is a font test
this is a font test

This is a header test

This is a sub-header test

This is a secondary header test

This is a whatever comes next test

This is a ... well, a test.

More to come..