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

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