My first 5 years in flywire

The other day we were driving around, and I noticed the odometer marking 99,960 km.
- Hey, check this out, we are 40 km left to make it to 100K
- And what will happen next?...
This was the question of our 9yo, always sharp to make questions to understand the context.
- Well, we will celebrate and then move on, continue our trip and when we make it to the 200K mark, we'll celebrate again.

This week I'm passing my first 5 years in flywire, I guess this is my celebration post before moving on and continue testing stuff.

The first week after joining the company I wrote a post about 5 differences from my previous job.
- I would have to write code for myself.
- We follow the agile principles.
- I have a laptop, and I don't have to punch in and out every day.
- There is a training budget, and I can choose where to spend it.
- This is an nice office with windows.
- I'm back to writing on a blog.

Looking back, there are some things I was not aware then, and I feel like writing them down.

- This is not just a job, this is an adventure. Like all adventures, some parts are fun, some aren't.
- There are a lot of nice people working in this company, and I can not tell how many times we managed to fix issues because of this, smart people trying their best to improve and to adapt.
- We have a delicate balance between many cultures, many ways to understand how to run a business, many challenges in communicating and coordinating, many things we want to do, many challenges we want to overcome.
- I still stand for what I wrote two years ago about what working in a startup was like, now we're just more people & more fun.

And also,  I keep learning new things every day about software, how to test it and about the people who develops and uses our product, so you know what?

Can't wait for the next 5 years and see where we might get.

Training a Corsair.

Spain has one of the largest forest areas in Europe, around 32% according wikipedia.

When the weather gets hot and dry, wildfires are a terrible issue. Not only the ecological damage that comes after each wildfire, but they also have a economical damage to the surrounding areas, as nobody likes to hike a burnt forest.

The Spanish Air Force has a unit called 43 Grupo who fly the Canadair/Bombardier CL215T / CL415  hidroplanes, they fly beyond standard safe flying rules, they follow their own rules, they call themselves the "Corsairs of the 43th"



When pilots get to the group from the pilot school or from other units, they already know how to fly, but not how to fly this plane, under these conditions, close to the ground, close to the flames and whiling to drop 6 Tons of water over the right spot.

Then they become copilots and learn by flying how to master their aircraft, and once they have been flying enough, and have a certain experience with wildfires, they get the training to become first pilots.

They don't wait for turnover to train people, the understand that it is better to have two experienced pilots flying the craft, than having many newcomers around.


One month has passed since MC joined flywire.

In this time we have been working together in coding skills, testing issues, reporting bugs, knowing people around, understanding the business, telling old stories about pricing matrices and partners in India and making plans to get to testing conferences.

We also spent time watching talks and reading books that would help us shape the kind of testing we do, the things that are important for us as testers.

Talks:
Rob Sabourin, Values in Testing:
Rob Lambert, Remaining Relevant
James Bach, Winning our reputation
Chase Jarvis, Cheap camera challenge

Books:
Lessons Learned in Software Testing.
Learn Ruby the hard way.
Perfect Software, and other illusions.
The Leprechauns of Software Engineering

And all this on the first month, not bad for a young corsair.

Support 43Grupo over Instagram and Youtube
The picture can be found here.

Being Context Driven Tester and defining Testing Community.

When I read the Context Driven Principles, and I think in the testing I do, this is how I interpret them:

1. The value of any practice depends on its context, so every time I see a testing problem, I try to figure out how can I add value. Sometimes I question the assumptions behind the feature, sometimes I test the way it works, or I try to understand the impact it might have when we roll it to production, and raise a question if I am not sure there might be a problem.
2. There are good practices in context, but there are no best practices. Being able to learn different approaches and techniques will enable me to choose the best way to proceed, instead of following a written rule about how testing should be done.
3. People, working together, are the most important part of any project’s context. And when it says people, this is not only the development team, but the rest of the people working in my company, our users, our clients, and the testing community. People who work developing features for the next release, people who teaches me things that will allow me better understanding, people who listens carefully when I am explaining something. The respect I have for all these people drives my work.
4. Projects unfold over time in ways that are often not predictable, and because we understand this, we automate some tests, we deliver in short iterations, so we get feedback as fast as possible, so we learn from what we just did and think if we want to continue the same path, or if we better try something totally different.
5. The product is a solution. If the problem isn’t solved, the product doesn’t work. As a tester, the first thing you want to do is to understand the problem, otherwise you won't be able to question the solution, whatever the solution might be.
6. Good software testing is a challenging intellectual process. And how you manage your life, how much you sleep, how are you able to defocus and to concentrate, what other things do you have to take care of, all this is going to have a direct impact in the quality of your work.
7. Only through judgement and skill, exercised cooperatively throughout the entire project, are we able to do the right things at the right times to effectively test our products. Judgement and skill are things you grow by learning and questioning, cooperation comes after respect and understanding, and knowing where the project starts and ends is vital to understand where you can add value.

So, as a tester in an agile team who delivers software for our own business, having automated tests, running CI, continuous integration, smoke tests, servers and environments up in the cloud, having Developers, Designers, Frontenders and Backenders, Reliability Engineers and Security Experts... these seven principles apply when it comes to explain the testing I do, the value I add to the team.

This is why I see myself as a Context Driven Tester.

The other thing I like, is my relation with a great testing community, where some other testers identify themselves as Context Driven, and some others don't. But what makes them part of (my) community, is that they provide chances to learn, to share and to teach.

First things first, Jerry Weinberg helped me understand what is my place as a tester in the team, and why it is an important role.

And then...
Michael Bolton taught me how to not trust my own beliefs. If a black ball was able to fool myself, imagine what a piece of working software could do.
Markus and Alan shared how to automate tests and when to do it.
Jon explained how to understand Session Based Testing.
From doing BBST and the feedback of my teachers I saw how hard can it be to perform as a tester and to write down my toughs.
Rob has great writings for performing web testing, and for hiring and training other testers.
Stephen was great teaching about Mobile Testing.
Maaret and Llevellin are doing a great job explaining Mob developing and Mob Testing.
From Huib, Pekka, Richard and Bill I got the chance to understand agile planning and working with mindmaps.
Santhosh is a true example of giving back your learnings to the community.
Simon provides a nice curated list of blogs to read
Keith made me understand how to scale testing, how to understand and respect other kinds of testing.
Michael Larsen showed me how to live blog when you go to an event, and how to set yourself targets and objectives for learning and growing.
Rosie and Morten both run awesome conferences, that gives the people the chance to know each other, share and learn experiences.
Henrik once told me I was the only Spanish Context Driven tester he knew, and this made me think about how to change that.
Tomislav, Marta, Gemma, Maxi, these are the local testers who will join whatever event I come up with, who will share their time for a lunch and talk about testing, who share my same passion and live in the same city I do.
And I'm letting others out, but you get the point, we share, we care and we evolve as a community.

And then there is James Bach. I learnt from this man to take care about my professional career, I learned that I can choose to be a snowflake or a rain drop in the mist, he is not going to teach me everything I need to know as a tester, but his work as helped me, and many others, shaping our career as software testers.

This is how the testing community looks, for me, today.

The end of one song means the next is about to start.

You know when you have a story in your mind, and a tune that reminds you to the story?

Miguel Angel joined our team in February 2014, I remember we were very happy with him joining our team because he was a good developer and a very nice person. He had a good programming skill and a deep agile methodology knowledge, he was a very good fit.

Busted flat in Baton Rouge, waitin' for a train
And I's feelin' near as faded as my jeans
Bobby thumbed a diesel down, just before it rained
It rode us all the way to New Orleans

At that time he was living in Dublin with his wife, and he started working as remote, spending one week every two months with us in the office.

I pulled my harpoon out of my dirty red bandanna
I was playin' soft while Bobby sang the blues, yeah
Windshield wipers slappin' time, I was holdin' Bobby's hand in mine
We sang every song that driver knew

As the team kept growing, we hired his wife. She was also a good developer, and we managed to keep them both working in the same place because by that time, we had two teams working in different things, so each one would get assigned to one team. They moved back to Valencia, and we kept moving on.

Freedom's just another word for nothin' left to lose
Nothin', don't mean nothin' hon' if it ain't free, no no
And, feelin' good was easy, Lord, when he sang the blues
You know, feelin' good was good enough for me
Good enough for me and my Bobby McGhee

Months pass very quickly, and we kept growing our team, we hired more developers, more testers, more Product managers, we kept being busy, holding our retrospectives, code reviews and so on. But at some point we started just maintaining our codebase, instead of aggressively shipping new features.

From the Kentucky coal mine to the California sun
There Bobby shared the secrets of my soul
Through all kinds of weather, through everything we done
Yeah, Bobby baby kept me from the cold

At some point, she left the team. Maybe the role she wanted to perform wasn't one we had, maybe we were not the kind of team she wanted to be working with...

One day up near Salinas, Lord, I let him slip away

He's lookin' for that home, and I hope he finds

 

I guess that when you remain in the bay for too long, and you don't sail stormy seas, some sailors leave the ship, because they get bored, they miss the excitement of building solutions that will change the world for good, they miss the thrill.

Let me put clear that I totally understand that the company has strategical needs, that we have to ensure that the foundations of our core business will be strong enough, that when we scale nothing will break into pieces... all ships must go into the dry dock from time to time.

But, I'd trade all of my tomorrows, for a single yesterday
To be holdin' Bobby's body next to mine

This week is going to be his last week with the team. Where he will be next I don't know, but I can only wish him the best. It has been a pleasure working with you, sailing these never-ending seas, figuring out how to solve all those issues we been through.

Freedom's just another word for nothin' left to lose
Nothin', that's all that Bobby left me, yeah
But, feelin' good was easy, Lord, when he sang the blues
Hey, feelin' good was good enough for me, mm-hmm
Good enough for me and my Bobby McGhee

Having Miguel Angel on board has been great, just as it has been to have Emma, Carles, Adrian, Gregorz, John, Aditya, Teresa, Marco... and every other fellow we had the chance to work with in the past.

Let's celebrate his departure, and continue our voyage, to wherever the next harbour is. Next steps are continue hiring great people, release features that will make us proud, have fun together and find our way to success.

Journey on.

Introducing the team

Let me introduce you the Flywire Engineering Team.


Building Flywire from Valencia from Flywire on Vimeo.

Some months ago we shoot this video, and hey, it is fun, it is not that long, and I'm quite proud of it.

This video serves two purposes:

• Make our Mama proud, yes, of course, absolutely.

• Help us getting known in town. Since we are hiring new talent to join the team, we think that this might help getting known before the first interview.

And that is why I wanted to share a post about it.

How to Talk to a CIO About Software Testing - Keith Klain

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:

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.