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

My best colleague

Today I spent my retrospective break thinking what I value from a colleague and why. The reasons were simple: identifying what is important to me, especially now that I’m reading Subliminal; and understanding what makes them amazing colleagues will help shape myself into one. This is obviously personal preferences, and as you imagine most of the points are not even technical. So let’s start!

  • Passionate about their craft. When you work with people that love what they do, they’ll try to do it better. And, more importantly, passion is contagious!
  • Critic, but not a Grinch. The main difference for me is proposing and trying different solutions instead of just complaining.
  • Up for a conversation. I want to be surrounded but people social enough that doesn’t cause awkward meetings.
  • Skillful. Right now, learning is what drives me the most, and my colleagues are an invaluable learning resource!
  • Resilient enough to take some jokes. Unfortunately, I love joking and making comes, and I’m more than pleased to take them back. For me, having the freedom of pulling our legs from time to time without dramas makes a huge difference in the team.
  • Not a diva. This collides with previous points, but by experience: Discussing with divas about some work related subject is not productive at all.
  • As different to me as possible. Because skill is not the only subject I have to learn.
  • Autonomous without fear to delegate. This is really hard to find, but having a team that you know will get the task done, and that they count on you is the most productive environment.
  • Healthier work/life balance than me. I know I’m lacking it, and if I surround myself with people like me it’ll get worse.
  • Open to socialise. I’m always the new one, and I love being abroad. Having colleagues open for a beer is needed sometimes.

Which are the virtues you value from your colleagues? I’m trying my best to improve all the points in this list. If I wouldn’t enjoy working with myself, I can’t expect anyone else to do so.

May the force be with you,

Gino

Tester’s commitments v 2.0

I’ve already talked about James Bach’s tester’s commitments, but I have problems making that promise to my colleagues, as I don’t share some parts of them so I want to create my own version. I want to include Quality Assistance values, as well as some experiences; and keep them as short, simple and relevant as possible. These are my commitments:

  1. I provide a service. You are an important client of that service. I am not satisfied unless you are satisfied.
  2. I am not the gatekeeper of quality. I don’t “own” quality. Shipping a good product is a goal shared by all of us.
  3. I will assist you in the design of the product to ensure its testability.
  4. I will support you in any task to deliver a better quality product.
  5. I will provide guidance in your testing efforts, sharing my knowledge with you and helping with any tool or technique needed.
  6. I will learn the product quickly, and make use of that knowledge to test more cleverly.
  7. I will help you identifying important things to test first and try to find important problems first.
  8. I will strive to test in the interests of everyone whose opinions matter, including you, so that you can make better decisions about the product.
  9. I will write clear, concise, thoughtful, and respectful problem reports. (I may make suggestions about design, but I will never presume to be the designer.)
  10. I invite your special requests, such as if you need me to spot check something for you, help you document something, or run a special kind of test.
  11. I will not carelessly waste your time. Or if I do, I will learn from that mistake.

I know that the list will evolve with time and experience, but these are the commitments I make today for you.

May the force be with you,

Gino

My experiences with pair programming

Pair programming has been one of the buzz techniques for a while now. In our industry, you can find groupies of it, professionals who understand its value but don’t know how to practice it and others who don’t see its value but will defend it anyway. Its value has been proved over and over again, so any developer who talks against it will lose points with his peers.

But I’m not here to talk about industry trends and tabus (microservices as the new default solution). but about my experiences with Pair programming, what I’ve learnt and where I’ve found value using it. This is the direct response of a “Which are the downsides of pair programming?” question during an interview. So… let’s start!

In most situations, when I’ve worked with developers pairing (either between them or with me), I’ve got way more out of it than the downsides. That’s why I’d love to start with the obvious advantages of the technique:

  • Getting early feedback. Code reviews are a standard nowadays, and pair programming is a live code review where someone is questioning your engineering practices. Also, it helps to spot some major issues.
  • Learning from different skillsets. Every developer follows his own book and learning other ways to do things (even if the difference is just minimal) which enrich your solution’s toolbelt.
  • More polished deliverable. When you deliver something after pairing, you know that it had been reviewed, probably tested (even if it’s just in your peer’s head), better practices has been followed (every shortcut will need an explanation, and you want to impress!). In my experience, pair-developed features need fewer interactions, particularly when the requirements were fuzzy.
  •  Work out assumptions and incomplete requirements. When requirements are not completely specified having someone asking you about the unconscious assumptions that you are taking allow the team to raise the correct questions to Product, and therefore need fewer iterations or (even better) don’t release with assumptions totally unrelated with the product. This is more powerful with cross-functional pairing techniques.
  • Cross-functional pairing. Luckily, as a Software Developer in Test, I’ve paired with programmers to get a better understanding of the solution, as well as helping them identifying potential problems and building more testable applications. I’ve seen this with Product people as well (designers, business analysts, etc.), although in that case instead of pair programming I’d call it assisted programming. Group programming is one of the evolutions, and there having cross-functional helpers will greatly enrich the development.
  • Avoiding the zone (or Flow state). Pairing prevents a developer to entering the Zone as we know it. You can get to a highly productive state with your partner, building momentum and getting answers and solutions straight away. As we stayed in the Clean Code review, some professionals try to avoid the Zone as it can prevent good practices being followed.

On the other hand, I’ve also discovered that Pair programming doesn’t have the same level of productivity (nor viability) on every given situation.

  • The speed. This technique may slow down the development, especially until the pair learn how to work together and build some momentum. It heavily varies on the developers itself, as it is…
  • Difficult for some archetypes. There are developers that don’t know how to pair, or they just can’t. They’re used to having their own introspection moment, usually relying on the Zone to get the job done at good pace. This is an amazing technique to spot this kind of developers if you want to avoid them.
  • Building dependencies. Some people get comfortable and rely on the partner to deal with certain kind of jobs, building a dependent relationship where instead of learning they can just use each other. Again, luckily this is not always the case, and it helps to spot this kind of developers to avoid them.
  • Avoid the zone. There are developers that heavily pursue getting into the Zone.
  • Requiring a pair. Working on startups, when you try to build cross-functional Agile teams it’ll be hard to find a pair to code with. If you need 2 frontend engineers, 2 building the services, 2 dealing with the operations, a designer, a product owner…

Which are your experiences with Pair progrmaming? Did you find it useful? Did you like it?

May the force be with you,

Gino

Lessons learnt from Clean Coder

Previously I talked about Clean Code, I want to focus this entry on how Clean Coder:A Code of Conduct for Professional Programmers (Robert C. Martin) made me evolve professionally. This book focuses on the professional aspect of a developer: the interactions with the rest of the team, the responsibilities of the roles, etc. I don’t know how to keep things short so let’s start with it!

How to manage estimations and its importance. Now you always have to work as a team, and in order to manage projects you need some time of estimation, and its the responsibility of the programmer to be as accurate as possible (and to research and train the technique).

How to interact with other roles in the Software Industry. Skills like managing expectations with the stakeholders, getting the best out of your QA, understanding the differences between a development manager and a developer manager, etc. A professional programmer is not only a good coder but an amazing team player. So take so time to learn everyone’s role!

The professional also carries the responsibility of saying no when the situation requires so. Everyone can say yes to anything and then deliver a shitty result, but you have to raise your hand when a situation will undermine your craftsmanship and end with a compromise in the Quality. Things like repeatedly doing overtime will end with some buggy and unmaintainable code, so saying no when there is no plan be, or the plan is to stay in that situation for longer than it should, it’s your responsibility.

Managing your time and schedule is also a really important skill everyone should learn. Uncle Bob talks about Pomodoro and other techniques, and it was the first time I realised about these amazing approaches. This has been a subject I’ve been working on for so long that you can see some of my latest results here.

He also made a controversial statement which I share. The Zone, even if you feel productive while staying on it, should be avoided and only used when the situation requires to. Entering that mind state will make you drop some of the best practices and induce you to decisions really hard to tackle and fix. That’s why he recommends not to listen to music while programming (making it harder to enter The Zone), and activities like pair programming or taking breaks from time to time (Pomodoro).

As said during the Clean Code summary, he considers Unit test as one of the main sources for code quality. If something doesn’t show how it works in a test, then you can trust its code.

A good professional is responsible for his art, so you have to allocate some time to train and improve your craft. Part of that time should be given by the employer, but you have to invest some of yours to stay always on top of your game.

He also recommends techniques like code katas to interiorize new languages, frameworks and tools; as they allow the practitioner to focus on the changes (as the problem is already known and mastered). He encourages as well to warm up with a coding kata before starting the working day, helping with all the bugs and failures that get introduced while you’re still getting into the programming mindset.

Personally, I found this book even more interesting than his Clean Code brother. This was the first time I start thinking about the surroundings of my career and how to become a better professional dealing with them, instead of just focusing on improving the code itself. A highly recommended read!

May the force be with you,

Gino

Gamificating testing

Gamification is one of those buzz words that you can easily find in articles, not only relating to the Software industry. There are numerous examples, both successes, and failures, but I want to talk about applying some gamification concepts to the testing world. I’ve never heard of any case, so I’ll talk about some things we tried and ideas I want to try in the future.

I’ll define gamification, so we are on the same page, as the application of gaming concepts to make a process or task more appealing to the practitioner. It usually involves a point system so the player can brag, some tier levels and perks related to them. In some cases, you don’t even have to give real rewards, like Reddit’s karma or StackOverflow’s reputation, as they rely on the power those systems have to gain recognition in very large social groups.

Obviously, they’re not appealing to everyone, although in my experience I’ve found some key factors that would dramatically increase its success like having a large enough group to contain some advocates of the game. There are always going to be detractors, but if you have enough people enjoying it the ball can keep rolling, and most of them are going to start realising the value. Keep the points meaningful and not easily obtainable, usually involving the players itself as the ones giving them. Allow players to brag about their points usually sharing a leaderboard. It’s usually better to keep rewarding the top players but avoid punishing the ones who doesn’t get involved.

How does this relate to testing? Well, as you know, we’ve been trying Quality Assistance for a while, and the biggest change is to convince everyone that Quality is a shared responsibility, and we expect some deliverables from them; for example developers should include their automated tests in the reviews, should spend some time testing a new feature, etc. One of the solutions we tried was including a point system where we reward the programmers who focus on quality, especially when they went above and beyond creating a testing demo, including non-functional tests, refactoring for testability or asking for help. We had a “testing padawan” in every team to understand how was it going. This way we could weekly showcase those coding rock stars: They felt rewarded, and we learnt which team should we focus our efforts on.

Other places where I think gamification would help us is in our user testing group. While we work on new products we seek for user feedback either for the prototypes and early builds. We find them among friends and family, power users or just random people. Ideally, if we implement a gamification method between our users, we can find the most engaged ones and reward them giving input for the new products, although this can be dangerous as most of the times new features are not targeted for these users. But when someone listens to you, it’s easier to get attached to a product. And that’s never a bad thing.

Can you think of any gamification example in the Testing industry? I’d love to hear it!

May the force be with you,
Gino