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

Subconcious testing

I’ve finished reading Subliminal recently and it confirmed an idea I always had: guts in testing make a huge different. I’ve already talked about great testers being born instead of trained. Experience, study and failing to teach you new skills to achieve better efficacy, but most of the decisions I take during testing sessions are gut-driven (and experience driven as well, always remember previous shit!).

The best (or worst, depending on your side of the game) bug discoveries I’ve made were trying something off record purely based on my instincts. Building that load test focusing on the weird interaction between components because several parts use the same database, or just letting my inner annoying user take control of the keyboard and mouse. Something tells me that the calendar widget may easily fail, and the payment app is not going to correctly handle high load.

This makes some conversation with developers tense because they want a reason why we can’t go live get, and waiting for me up build a test that will check something that we don’t have any evidence yet that it might fail is not a valid reason. With time, they end up trusting my guts as much as me; but I find wise to hold it while you’re still building that trust, as it’s not wise to have your new team against you during the first weeks. When they see its value, they stop thinking that is a waste of time.

It also makes Quality Assistance methodologies trickier because teaching reasonings that are not fully conscious requires a deeper knowledge in the field. I like analysing my actions after doing them in order to understand the reasons and having an easier time explaining them.

But, if testing is about guts, how can we train it? For me, analysing my reasonings helps me identify what I correctly did and where to focus my efforts; and observing my colleagues asking for reasons make me understand new ways and approaches. It’s hard to learn from other’s experiences, but it’s still better than nothing. That’s why I prefer reading about testing cases and stories rather than studying. But there’s still a long road ahead so, give me a hint, how do you do?

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

 

It’s always worse elsewhere

Yesterday I share a couple of beers with some old friends who also work in the Software industry. They’re working on a small Consultancy agency building websites using the same core, cutting most of the production costs as most of them use fairly similar implementations. Everything sounds right until they get surprised when I asked about their testing framework. “Well, before sending them to the client, we navigate through the site checking that anything breaks”. Fair enough, I don’t expect everyone to use Selenium. “The problem is when a client finds a bug. Most of them are part of the core so that bug is probably on every one of our projects, and we’re afraid of refactoring anything”. If the core is not a volatile piece of code, probably it’ll be a good investment to build some functional tests verification on top of your unit test. “Unit what?”. Bum. And then I remembered.

I was also part of a Consultancy brand (it was my first job in the industry). I remember the “we can’t afford to write the unit tests, our problem is really complex and we don’t have time, we’ll just verify it at the end”. I bought it. I truly believed that we were good enough that unit test was only a plus, and the projects were difficult and fast paced… NO WAY we could afford wasting time on tests! I remember some senior colleagues explaining that to me. Why would I don’t follow their example? They had way more experience than me, and they developed way faster. I wanted to be like them.

And I remember the struggles. I remember that every single bug fix carried weird and unexpected regressions. How the clients complained every week, and the constant fight about who is the responsible for the fix (Was it a bug, or a failure in the requirements?). The hellish deployments, the tedious manual verifications of just what was needed, the numerous problems with our version control tool as we always realised too late that the release didn’t contain that change.

I also remember the change. When I left the company and learnt something new in the next one. And then the next one. On my first day, one of my new colleagues was disturbed because I wasn’t writing unit tests. He didn’t even ask a reason, but I tried to convince him that they just slow my momentum. I remember his face. He just taught me how to make it easy, and handled me a copy of Clean Code. I had to pair with him and… Oh God, that was beautiful. He showed to me what TDD feels. And I started realising that, actually, the team didn’t spend that much time dealing with the horrors I was used to. It was so simple and beautiful.

That’s why I spent some time yesterday trying to show them the importance of this practices. Explaining to them why most of the companies they want to work in ask for TDD practices or writing functional tests. Exampling to them how they’ve been important during my projects. Giving them resources, guidelines and the chance to ask any question. But, obviously, I’m just a QA, so what the heck I’d know about coding.

Yeah, dear readers, it’s always worse elsewhere. That’s no excuse to not try to be the very best you, including the best professional you can be; but sometimes appreciating what you’ve learnt and why you’re doing it is needed. It is also important to identify who would use some help, and offer it. For me, life is how you feel sharing with the people you choose your knowledge, resources and smiles. I’ll talk in further posts about some of the

I’ll talk in further posts about some of the anti-patterns I’ve seen (and do) during my career, and some lessons I’ve learnt fighting them. But, for now,

May the force be with you,

Gino

Why being a tester spoiled my life

I truly believe that a great tester is born, as well as most other professions. Testing requires a strongly critical thinking, as well as perseverance and lateral thinking. There are some technical and products details that undoubtedly help in your daily work, but in my opinion, those skills don’t make a great tester on their own.

I’m not a great tester, and that’s what is driving me to understand, learn and practice how you become one. But I’m a critical thinker. I love breaking down situations too, in the calmest possible way, and identifying what is happening, which are the potential outcomes and how can it go wrong. I’ve been doing it my entire life, and probably that’s why I enjoy being a testing professional. But I can’t stop being a critical thinker in my personal life.

There are times, MANY times believe me, when spoiling yourself thinking what can go wrong will ruin an experience. There are times when understanding why you ended in some situation make it way less enjoyable. And, if you’re sharing it with someone, people will hate you when you try to anticipate the issues and prepare a plan B in advance. Some just want to do things, regardless of the result. A simple example is my peculiar relationship with food.

My mum in endocrinologist, and I grew up learning the calories of the food, which are their main nutrient and what is missing in any meal. And that has spoiled my life. I obviously eat junk food, and I enjoy eating colossal portions, but I can clearly point you how it will affect me, and what I’m doing wrong. So when I see someone eating a really big budget with doughnuts as buns, I just can think “SERIOUSLY??”, instead of enjoying it.

But peeps, if you’re cursed like me, remember that you can use it and become part of the testing community. Your colleagues will praise your ability to anticipate fires, and they’ll learn it after throwing away your recommendations; you’ll help people understanding why things didn’t work and you’ll show people that some details really matter.

This is why I’m still a tester. I spent part of my career pretending to be a developer, dreaming of being a designer and even thinking how would be producing. But I’m cursed, I was born to be a tester, and breaking things is SO funny.

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