The book of the five rings: Why

I’m enjoying The book of the five rings (Miyamoto Mushashi) way more than what I thought. It’s not only teaching m about martial arts and war but all the lessons are easily applicable to professional and personal situations. Even if I wish to never have to apply this knowledge about sword mastering in my real life (although with my passion of role games, I know they’re going to be handy!), revisiting some experiences in my head as they were a duel, running through all the points Mushashi explain in this amazing book.

What hooked me to continue reading (on top of my inner nerd feeling like a ninja!) was how surprisingly relatable were the lessons and statements to my career. And we’re talking about a half a century old manuscript about surviving duels to the death.

For instance, Mr Mushashi talks about how a bad rhythm can kill you. Moving too fast in a fight is as bad as being slow, as you might make a mistake. That’s why he always keep a steady pace: fighting, walking and living. It allows you to study your opponent and plan a strategy.

He also says that repeating a technique that previously failed will kill you. You might be tempted thinking that the failure was because a bad performance, but the chance of another failure is really high. If you tried it and manage to survive, your adversary will be ready for the third time. And you’ll die.

He stays the importance of your environment. Every one of its details might be an advantage, and you have to avoid that they become an adversity. You should also have expertise with a large variety of weapons, not just mastering a few of them like other duelling schools. Adaptability is required if you plan to keep duelling and survive. People will bring new weapons and tools, and they’ll focus on countering the common techniques.

As he says: no technique is invalid if it makes you survive. I want to end talking about the book with some if its quotes:

“Do nothing that is of no use”

“It is difficult to understand the universe if you only study one planet”

“You can only fight the way you practice”

“You must understand that there is more than one path to the top of the mountain”

― Miyamoto Musashi, The Book of Five Rings

May the force be with you,

Gino

Efficiency obsession: Power Reading

My biggest quirk is this stupid obsession with efficiency. I’ve spoiled every aspect of my life because of this, and the saddest part is that I enjoy it. When I have a new toy the joy of discovering it ends pretty fast, and I just want to learn how to get the most out of it afterwards. Most of the times, I don’t even need to apply that knowledge; just learning, discussing and testing it is more than enough.

I do it with almost every aspect of my life. When a get a new video game and I enjoy the mechanics, I start learning and theorising how to min max it. How to get the most spending the least time, how to break its virtual economy with handmade cost-related spreadsheets, etc. When I walk, I always think the fastest way to get somewhere, even when there’s no hurry. When I have several episodes of a TV show pending, I watch them at 1.5x. Daenerys listing her titles improves at 1.5, believe me.

And obviously, it also affects my career. I won’t talk about its implications for my daily work now, but how it changes how I face my continuous learning. I’m in the first steps in my career and have plenty of free time, so I usually try to spend a fair amount of it trying new technologies, reading about last trends, doing courses and reading. It’s not always related to my field (like The game or The Book of Five Rings), but instead of reading fantasy literature (which I love doing), I’m focusing on amazing papers that teach me something.

But how is my stupid efficiency obsession affecting my reading? I don’t know how familiar are you with power reading techniques, but lately, I’ve been following this one. I’ve always been a fast reader, although my speed is heavily hammered with technical English-written books. That’s why lately I’ve been trying some of these techniques, to get better comprehension and faster assimilation of the concepts.

I know, the main concern is: you should be enjoying the reading, not rushing it! And that’s completely fair. But as I said, the main reason for reading these books is to increase my expertise in an area, expanding my knowledge, learning new approaches, and summarising the best ideas of it. Power reading achieves all these purposes, along with training a very useful skill in my opinion: reading a really long text and assimilating its key concepts.

“But reading fast is really easy, you only have to skip some paragraphs and voilà!”. I’ve also been there. I remember my tedious maths reads, and how I tried to skip everything that didn’t seem enough important. But this time, I have another powerful tool: this blog. For every of this book that I read, I force myself to think about a lesson learnt post, and I start writing a bullet point list of the main subjects and the things I enjoyed the most. Even if I don’t polish and publish the post, it forces me to understand and pay attention to the read!

May the force be with you,

Gino

Cool automation tools

Few months ago I started gathering all testing articles and examples that I came across. I have a really awful memory, and discussing with my QA Lead about different approaches I could just remember some of the details, which led to awkward conversations; so starting to build my own “Testing Bible” sounded like an amazing idea. And so I did.

It’s actually a Google Doc where you can find chapters about specific testing methodologies (Rapid Software Testing, Quality Assistance), automation tricks, arguments to convince stakeholders and developers, a bullet point list of my achievements and some cool automation examples. Today I want to talk about the later!

I really love hearing about tools or techniques that organisation has developed to meet their really weird and niche testing needs. Google Testing Automation Conference is an amazing place to find some of them, as well as companies with tech blogs (although in some cases they think testing is not an enough appealing subject to talk about). So let’s talk about some of the ones I felt in love with!

Netflix Simian Army

This is bringing fault injection (https://en.wikipedia.org/wiki/Fault_injection) to the next level. In order to build a resilient system, Netflix realised that they need to be ready for errors. The best way the found to probe it was injecting errors in the pieces that are out of their control, so they understand what’s going to happen when those genuinely occurs. The talk is centred about the army of simians that they have causing AWS errors in production.

Things, like killing AWS instances or faking an entire region downtime on Amazon, are the duties of this monkey gang. They periodically trigger them on production to see the progress and be ready for when shit happens. Because we know that shit always happens. Part of the source can be found here.

Facebook’s test killer

As I’ve already mentioned, Facebook is known for not having Testing roles. They heavily rely on automation, although we know that flakiness and inconsistency is one of the biggest pains automating tests. That’s why they’ve come with a system where tests have to gain trust before the system will consider them as necessary; as well as a way to identify, heal and fix tests that cause more noise than benefits.

The system automatically marks the failed tests as “unknown value“, passing them through various states and identifying the responsible of it. It helps to review the code, and the system is the one disabling someone else’s test when it starts feeling flaky, so it’s not a “me against you” argument.

Generate tests from logs

Creating a complete suite of unit testing can be a daunting task. particularly when you scale up the product size. With this solution, they rely on an extensive logging and machine learning techniques to generate stateless and contextual assertions, building the skeleton of the functional tests.

You’ll still need some human intervention, but this is undoubtedly an amazing starting point, leveraging the most tedious part of the process. This is proper automation: something that assists us to achieve our goals!

Spotify’s Rapid check

Testing all the range of values in a unit test is impossible, that’s why Spotify has used the RapidCheck idea to help them build better coverage of the range. It randomly tests a broader set of values, setting a skeleton of important cases. Every tool that helps us get confidence on the solution faster is welcomed!

Do you know about another interesting testing tool? I’ve left some of them unsaid, but only because I love having pending subjects to talk about in future posts!

May the force be with you,
Gino

How my desk affects my work

One of the amazing perks of a startup is the small office and teams, allowing you to spend plenty of time with colleagues from other fields. I’ll write a post with all the amazing things I’ve learnt working with product managers, designer, developers and customer support; but today it’s about something different. I want to talk about how changing who are you sitting with will drastically change your experience in the organisation, and even your career.

Keeping your team in sight-distance is easy with our size, and it gives us freedom to move around without compromising the Agile manifesto. We’ve also moved three times offices since I joined, and completely changed the org and teams a couple of times; so I’ve changed my desk on several occasions. I’ve been sitting close to the development team to convince them about the testing importance, with my manager to better define the roadmap and priorities, with the designer just because we’re close and I’m so funny she wanted me there (OK, no), with our customer support guy… and every single of those experiences gave me a better understanding about our product and mission, and taught me something. Both personally and professionally.

Some experiences were more enlightening than others. For example, working close an introvert colleague might produce less conversation about life, the universe and everything else; but you might be able to ask more details about his daily work, and how you can assist him. Other times is your colleague who directly asks you for help. And bonding just talking about the weekend is always a huge morale boost in the office, and you never know when you’ll need it!

For example, sitting with our Customer support guy has completely changed how I approach testing and building the product. It gave me a lot of insight about what the users are complaining about, he engaged me with the community (it’s really useful the I think I found a bug forum!), helped me understanding how to test something, and taught me some legacy parts of the platform. I also helped him understanding how we’re building the new one, reminding him when a change was going to be released, teaching how to find technical details of the cases, and giving faster answers to the user.

With this, I just want to point out that you should care about where you’re sitting, especially if they let you chose! This is going to be part of your onboarding, and it’ll shape your career and experience in the company. If possible, I encourage you to change your place from time to time and visit some of your colleagues pairing with them some days (more about it in future posts!). Less process and organisation empower us, and this is one of the main reasons why!

So look around your desk and think Who should be sitting with to better learn how things work? Who is going to teach me more about X? Where I can be more useful?. No good manager will block you to change providing a valid reason, and testing your manager with the question is valuable on its own. And then… share your experiences with us, please!

May the force be with you,

Gino

 

My last year

Now that I’m wrapping up my work while getting ready for my next challenge (I’m really looking forward starting the project!), I feel like it’s the best time to make a personal retrospective about what I’ve done and what I’ve learnt. So… here we go!

Working in a startup has been my career’s most enlightening experience by far, both in the technical field and how to interact with my co-workers. Before joining, I was trying to avoid by any means taking responsibility for management or process tasks. I was young and technical, so I just wanted to code cool things while someone else was taking focusing on those tasks. But I was really lucky. My manager dealt with all the bureaucracy while empowering me with the technical details: she just told me what problem we had to solve, and I had the autonomy to decide what and how to build it. But some of those problems didn’t have a technical solution, so we start discussing processes, managing stakeholders, changing the testing mindset, etc. She introduces me to the Quality Assistance idea. It was SO challenging and fun! I was able to still use my technical knowledge while trying different testing approaches in the organisation. I also learnt that proper Exploratory testing is not the tedious manual testing I was thinking of… and it’s SO useful!

While reviewing our processes, I learnt that people, even when they identify the problems and acknowledge the solutions with me, some of them are really reticent of the change. They can complain about the current state and use it to justify behaviours, but embracing some changes which modify their daily working routine is not part of their plans. It surprised me because I spent days hearing them complaining about all the things we were trying to change. I’ve also reinforced my intuition: brilliant developers who are productive and build beauty solutions, are the ones caring the most about testing. And, as a rule of thumb, when a developer doesn’t care about testing they won’t probably the best code professionals.

It surprised me, but I learnt that startups and small size companies are not immune to lackluster management, to keep people who don’t give that much value to the team. I’ll expand in a future post, but I also learnt how to kill an organisation just destroying the culture. Because cultures matter. A LOT. I didn’t realise any of the extra mile works I was doing voluntarily until the culture died to blow up the morale levels and I started asking myself why I was doing them.

Regarding management, I also discovered that iterating fast and failing is not easy, and it’s not always the best solution. MVP was a meaningless buzz word that stakeholders always used. It was the best excuse to deliver an incomplete, unuseful and low-quality product trying to validate a market who preferred sticking to the old and more reliable product. Apparently, it is OK to release an MVP knowing that it won’t handle the expected load, or without the feature that most users are asking for. I’m looking forward to learning how to build real MVPs because I’m quite sure this wasn’t a good example.

On the technical side, I’ve learnt A LOT about machine learning and path, to the point of enroling in Standford’s machine learning course. I’ve learnt the beauty and the power of those algorithms. I’ve been thinking about testing applications based on machine learning, and I hope spending some time on that soon.

I’ve honestly learnt a lot and enjoyed my experience.

May the force be with you,

Gino

The no-QA way

We’re still finding out sweet spot regarding Quality and there are always some developers that think no “formal tester” is needed in our process right now. This approach even gains more followers when you have an ex-Facebook in your team.

Don’t get me wrong, I never take the bait to jump yelling “You NEED me, this will be a MESS without me!”, mainly because I think this approach is as valid as any other if you focus on the right things, and meet some conditions. And I really enjoy discussing testing, especially when it allows me to understand my peers’ point of view.

So we started a conversation, but it didn’t lead to anything because we were just pointing the pointless parts of our current process, instead of really talking about how to make it work. Afterwards, I schedule some time on my calendar to sit in one of the meetings rooms and use the Whiteboard to clear my ideas. Would it be possible? What are we missing to get there? What would it offer us? How would it impact our team and process? Which are other solutions?

Then I felt way more ready to have that conversation again, but I decide it will improve with a broader audience, and sharing the questions in advance so everyone’s is better prepared. And, this time, I really enjoyed the chat. We still complained about what is currently failing, but we managed to come with tentative solutions. As well as some answers to the previous questions.

Let’s start with motivation. What would it offer us? The answer was almost unanimous: less friction in the process. As developers will be more autonomous and the QA layer is not going to be annoying, coders can focus on the code. It also carries some challenges, but we’ll talk about them later on. The goal is having a simpler and smoother process, and also, you don’t have to spend on QA itself. Win / win situation!

But, obviously, there are some requirements to get there. So, what are we missing to get there? First and more important, by far, is the culture of owning quality. If there won’t be a “quality gatekeeper”, everyone should be responsible for their deliverables quality as well as ensuring that everyone’s working on it. We’ve been moving towards that (as well as most of  the Agile testing approaches), but we’re not there yet and it’s really needed making this huge step.

This is especially tricky when you think about testing the “big picture”. It’s quite straight forward that when you deliver your solution, it should contain unit and functional automated tests verifying its behaviour. Hopefully, you have a culture regarding integration and component testing as well. But what about ensuring that the application works as a whole? Who will be responsible for that? Who will create, maintain and run those tests? What about the strange and complex cases that are almost impossible to automate? When and who should explore it?

One of the huge differences between the Facebook and our case is the amount of dogfooding that they do. We don’t have beta users, we don’t do canary releases, we don’t even use our tool that much internally. That’s one of the biggest challenges that we’d need to solve before taking this approach. It can be done, things like getting used to exploratory testing the application after when the development is done, but no developer is used to do it. One of the reasons why Quality Assistance keeps a testing expert available for the team is to help in this transition.

Then… how would it impact our team and process? Well, spreading out the responsibility about quality need some process changes, like defining some steps or techniques to review the solutions in pairs, not only reviewing the code and the tests. Get some understanding of the application that we’re building, and we need to play with it if we want to verify the changes. We’ll need more involvement with the product in order to find dependencies and better testable solutions from the beginning, although it will improve after the team gets better knowledge about it.

So, would it be possible? Well, one of the Agile principles I TRULY believe and share is “Fail fast, fail often”. As long as we timebox the try, set some retrospective meetings and are aware of the potential impacts; I think is stupid to answer the question instead of trying it out for a while, analysing and understanding the outcome afterwards. For sure, the first version won’t be the good one, but will teach us some tricks for the next one.

And which are the other solutions? I’m still keen on giving it a go, so it helps us identify what are we missing from the current approach and what we love from the change. But it’s always good keeping other solutions in mind. We can always go back to the old model of a QA wall where we throw everything, having someone to help us embracing quality and building tools to aim us (Quality Assistance), heavily invest in automation, or whatever pop your mind that might work.

There are thousands of different approaches to find Quality at Agile speed, and none of them works flawlessly. They neither work in every organisation. And I know a thing for sure: spending time and resources on finding a sweet spot for your process is always a good investment. Period.

Do you have experiences with a non-QA environment? I’d love to hear them!

May the force be with you,
Gino

Developer archetypes

During my career, I’ve encountered numerous and very diverse professionals, which is one of the best perks of teamworking: you have to try really hard to not learn something from the experience, because learning how NO to do things is even more important than learning the best way. Reacting differently is always a factor that will empower the team as it’ll allow a wider expertise. But, obviously, there are some behaviours which help to build teams, while others make it challenging.

As most of my working hours are between developers (right now I’m the only QA for 15 programmers), I want to focus today on describing the different developer archetypes regarding Quality I’ve found, as well as sharing some tricks I’ve learnt dealing with them. Let’s start!

The “testing is not needed” one, which have two branches: “I’ve never seen proper testing, so I don’t see value in it yet”, typically found on junior profiles or professionals coming from experiences where no one cared about good practices; and the “My code doesn’t need to be tested” which can be even found on really senior profiles. For me, the wisest tip is focusing on them as few as possible.

When they start seeing the results from the others and realising that they’re getting behind, that they’re less shining, is the time to offer yourself to help them as much as needed. Your job is to make their work look awesome, don’t forget the commitments!

The “I don’t have time for testing” one, typical from junior profiles as well. They know that writing automated tests is valuable because… Well, probably because they’ve read that somewhere, and they know people expect it from them. Most of the cases they think there’s no time because they don’t know how you make them, so it’s a daunting task. The best that you can do is showing how easy is to get value from the tests. Handle them a framework with an example, pair during their first implementation and support them at the beginning.

If you see they become needy (what happens way less than I thought), gradually stop giving them that much support, coming from time to time to ensure they don’t get stuck. I’ve found that sometimes spending time explaining how this new skill is needed is they want to step up their career at some point towards “one of the big names” is really helpful.

The “I’m too biased to test” one, especially when you start talking about approaches like Quality Assistance and making them autonomous sharing the testing responsibility. They’ve heard that a developer can’t test, he’s biased, and that’s the perfect excuse to not even try it. The most successful way I’ve found to deal with this is focusing on the keener to test team members, sit with them and teach some tricks and examples. They love solving puzzles, and breaking systems!

When those colleagues are motivated enough, convince them to pair with the “biased” developers so they can test the new features together. Seeing a peer testing their code will show them that it’s possible to do it, and realising that when they review the dev on test feature finding way fewer bugs… Well, data is more convincing than words. And shame, more convincing than anything.

The “So, how can I test…?” one. This is the dream. These developers know what testing achieve, they understand that delivering a solution doesn’t mean anything unless it’s a quality one, they see value in the automated tests and prefer being the ones finding their shit. After seeing them work, and enjoying the results of their effort (fewer errors on their developments); they get your trust and you can focus the efforts on the rest of the Archetypes.

That doesn’t mean all the work is done. We assume most companies aim to have these developers, and sometimes you’ll be blessed with loads of them in your project. Now you can start working on what they’ve hired you to do. You discuss with them to build more testable products, review their work, build additional tools, assist them on the hard-to-test features, and experiment with new approaches. This is the dream. And that’s why I’m spending all my effort right now to convince as many developers as possible.

I don’t want to finish without naming one of my favourite archetypes: the “then, what are we paying you for?”. At the beginning, I wanted to answer them in a similar way but… wasting energy won’t take you anywhere. That’s why I keep it simple now. “My job is to review you until you become autonomous. Then, they can make me redundant or I can start focusing on the interesting stuff: doing whatever it takes to increase the Quality of your deliverables”.

Have you encountered different developer types?

May the force be with you,

Gino