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

 

Advertisements

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

Defining our QA process

As I mentioned before, we’ve been going through some structural changes recently. If we add to the equation a really tight deadline where we decided to drop the process and survive however we can; now we have some madness around. And, one of the craziest fields is quality and testing.

That’s why I spent half of today in a meeting room discussing how can we do, what can we try and why is so important. And, guys, I have to admit that I’ve enjoyed the experience. This is one of the first times I have to propose and implement a process on my own and… Such a shame I can’t share with you all the details and products from that meeting. But I can tell you what worked and what I learnt.

I always fancy starting with why we need the change; this helps to highlight the issues, stating that it’s not only impacting the people involved and we have to work together the solution. I started detailing how every team is dealing with quality right now (without process, every team has adopt QA on his own way), summarising it in bullet points as potential solutions and asking a really simple question afterwards: “right now, if you have to develop a new feature or refactor a piece of code, would you be confident enough to push it to production right away? “.

Obviously, we don’t want to push things blindly, even if the developer promises us how complete and awesome the solution is. But, if the one doing it doesn’t even have the confidence to make the step… Something is missing. So we start discussing why that was happening, and what it needs to change to get there. As you assume, the first solution was obvious.

Automation. We know how useful it is, especially helping us trusting a refactor and preventing regressions. As you should know, the team less confident about their code changes was the only doing less (none) automation. In my opinion, the main reasons were: lack of expertise, and without knowledge is easier to see some practices daunting and don’t realise its value; and a more complex automation problem, because UI are always more tedious to programmatically test, and without expertise you don’t know how to build testable products.

We discussed how to incorporate automation in our process, how can QA (just me) and Product leverage the task, and some technical details about the challenge. As some teams are using BDD, I propose The Three Amigos technique to define the tests, and I’ll provide them with examples, guidance, and support during their implementation; although they were really vocal about being the ones trying different frameworks and solutions. Fair enough, it’s going to be your child, I understand you want to choose it. Automation, checked. This will prevent some of the regressions, build back some trust and make them realise how untestable their current solution is, keeping that in mind for future builds and projects.

But, I’ve already told you that Automation is not the one and only solution, and there are some circumstances and problems where automation is just the inefficient and overkilling solution. You won’t write every possible test in the code, as it would be impractical. That’s why testing it manually, particularly new features, and getting feedback and soon as possible will help us meet Agile speed. Remember what I said of Quality Assistance).

That’s why I proposed QA Demos, where the developers show the new feature to Product or QA, and we try to break it in front of them for some short period of time. This way we can get the obvious feedback really fast, and developers can learn how we test. If we do it enough times, there is going to be a moment when they’ll be able to do it autonomously, knowing that their releases will contain fewer bugs, and building a better product because they have tested in mind. It’s a huge win situation, although there are some challenges (the biggest one I want to talk about it in my future post: Developers Archetypes).

This solution was less popular. They were sure that asynchronous solutions are more efficient, so deploying something and testing it whenever we can makes things faster (apparently, the industry doesn’t share that statement). Luckily, we decided to try it out in a couple of stories per sprint and check how it goes.

I finished the meeting with the QA manifesto, wrapping the actions, discussing some of the details and feeling that I’ve made a huge step in my career. I’ve done it on my own, and now I’ll try my best to achieve a process where we can trust our changes, and hopefully where the Quality Assurance role is not needed because everyone is ensuring the Quality of our product across all the journey. So, guys, I encourage you, if you don’t agree with the process, if you spot lacking points, try to change it. People is keen to improve what they neither like. They’re more supportive than you think. Well… Sometimes.

May the force be with you,
Gino

BDD: not by cucumber alone does man live

Don’t get me wrong, I know how useful BDD is cleaning test reports, grouping different frameworks and giving the ability to scale as it allows non-technical people to expand the feature file. But it has loads of painful points which makes it a powerful tool bridging the gap but most of the complex scenarios are impossible to handle.

That’s why, after some time using it as the default BDD as the default option, I understood its value and now I only use it for the simple and repetitive workflows, allowing anyone to easily understand what’s the current coverage of the “pre-commit” verifications. It also brings a common language for developers, testers and business people to specify the product’s behaviour, as explained by the Three Amigos approach, making it an awesome tool for clarifying misconceptions.

But I’ve found some difficulties implementing it. Since it’s foundation it heavily relies on TDD practices, so implementing it on teams not used to TDD techniques carries an extra challenge. I haven’t found proper documentation for the test implementation, as most of the articles online only state how empowering it is for business people. It requires a rigorous delimitation of what should contain every scenario, breaking them into really small modular ones which goes against our common belief.

Most of the implementation problems happened when we tried to reuse our BDD framework (made with Python and Behave) which was fitting flawlessly one of our small REST API testing suite, into a more complex project. We started lacking some context management, sharing variables between steps, dealing with multiple users… So we try to evolve our framework to the perfect machine that would handle it all. And it became a beast. We started to deal with “worlds” per test suite (a world for the billing system, another different one for user management), that way we wanted to keep things as modular as possible. So it became an ugly beast.

So, at that point, and being coeval with my “I don’t trust in anything I know anymore” moment, I decided to start focusing on “is BDD really what fitting us?” instead of just “how can I make BDD fit us”. Is it delivering more value than a traditional automated test? Are we using it correctly? What are the alternatives?

That’s how we realised that in some projects it wasn’t the way to go. For instance, when we deal with complex user scenarios and we’re not going to scale the test adding new repetitive steps, it didn’t make any sense to spend most of the time adapting the BDD framework. In those cases, we kept the structure for a consistent reporting, and we dealt with the test on the old fashion way.

Did you find any limitations on BDD as well? Is it fitting your needs seamlessly? In a future post, I want to talk about some examples that caused us problems. In the meantime,

May the force be with you,
Gino

P.S: If you want to dive deeper into the BDD world, you may enjoy these resources:

Meet Quality Assistance

Quality Assistance is a shift in the Testing industry that focuses on empowering the developer with testing knowledge and guidance so the development process can enough Agile speed. The principal promoter of the change is Atlassian, although some other companies are starting to embrace a similar approach (like Spotify)

In this video, Penny Wyatt (Atlassian) beautifully explains why they decided to try Quality Assistance:

Personally, I’m in love with this way to introduce Quality in software projects. I learnt about this approach from my QA Lead and we tried some of the ideas in our startup, learning in the journey some of the challenges needed to embrace it. We learnt how to deal with different developer archetypes convincing them that our goal was empowering them, not procrastinate because we were sharing Quality’s responsibility.

Particularly, I love that I spent most of my time on activities I love doing with this approach, such as revisiting processes, breaking them down along with the product itself looking for dependencies and bottlenecks to focus on; pairing with the developers learning the technical details of the product while I show them the joy of the puzzle of Testing; spending sometimes automating tools, enhancing frameworks and improving automated tests… it was such a win-win situation for me when we embraced this approach!

Obviously, we also encountered walls and difficulties and realise that there is not a simple way to adapt this methodology without customization, iteration and a fair amount of time. Most of the challenges are related to the need to change how most of the people work, being particularly difficult if you find some reluctant to change developers.

It’s impossible to tackle down the details of this encouraging shift in one post. I’ve included some really interesting documentation that I recommend you to visit, as well as the promise to detail in further entries some of the aspects of the approach, and some experiences dealing with it.

For me, Quality Assistance convinced me that Testing is where I want to be. I spent a big percentage of my career thinking that Development is what I should be doing, but I enjoy way more the tester role from Quality Assistance than programmer’s one.

May the force be with you,
Gino

Resources: