Bugbashing works

My last client decided to continue without dedicated testers. They hired me to help their teams out with quality instead. This was exactly the challenge I was looking for!
First few weeks I did the testing for them. We then looked around for a system that worked where I’m not the gatekeeper for what goes to production. So I organized a one-off bug bash session.
A session where everyone of the team spends 45 minutes to look for bugs and finish it off with a debrief of 15 minutes. We found so many bugs in these 45 minutes, we spend almost 45 to go over them! We spent too much time going in to the bugs, lesson learned. After this session the team was sold on the idea. After this we started doing them weekly!

How we ran our sessions

So every Monday we’d use the standup to agree on a focus for the bug bashing session. At 13h I’d post a thread that would be used to post a screenshot and a short description. Then after 40 minutes we’d join the debrief call and go over all the issues we found. The search would be async, where the debrief would be sync. This allowed people to search with focus and purpose.
In the debrief we’d discuss why this is an issue and who should solve it. We’d sometimes wander into how to solve it, but we’d try to avoid that as much as possible to keep the debrief concise. With the solving team appointed the issue would get a emoji as a tag. A volunteer would then create tickets for tracking purposes and post the result.

Advantages and learnings

Making this part of our strategy had many advantages for the team. They really took ownership of the product and it’s quality. They knew the state and could release with confidence and knowledge. Everyone knew about all issues and the state of newly developed features. The gap between designers, back-end and front-end engineers closed as they became 1 unit. Engineers had ownership about their own domain and knew their colleagues’ domain.

I’m proud of the work they delivered and they can be as well. The ownership they took, progress they made and product they delivered!

Advertisement

How I structure my postman space

Running across multiple environments

I’m using postman to run my automatic tests. But not all code is available everywhere.
But all code is first available on TEST than goes to PREVIEW than PROD. This also means that code on PROD is also available on PREVIEW and TEST. So after some experimenting I came up with this system.
I have a folder structure like this:

^{You can click on the image and see the request in postman docs.}

Now, when I run PROD, every request in PROD is executed. But running the PREVIEW folder, not only the PREVIEW requests but also all PROD requests are executed! Same goes for TEST, executing TEST, PREVIEW and PROD.
With this setup I can control which tests are run, depending on the environment. A new endpoint will be deployed and the tests are moved. This also works for new versions or updates to endpoints. It makes running the tests managable.

Multi-tenant setup

What I learned doing code reviews

Recently I started doing something I’ve always wanted to do but never actually got into: code reviews. I have some prior experience with code but not enough to write on an enterprise level. I always feared that my lack of ‘coding standards’ would be a big barrier to break. However, since reviewing code for a month or two it is going better than expected.

This is a story of how I found a new way of providing value.

During this time I mostly learned by looking at the code reviews other team-members were making. Seeing what kind of remarks they gave and applying that in other pull requests (PR) that I would review. In the end the PRs must be approved, which I don’t often do based on just a code review. Luckily the PRs are deployable themselves, and thus testable.

Reflecting on the last project

My last project was in the financial sector. The product we made was used by private banks. Our users were the Investment Managers of those banks. They are called the rock stars of the banking world. Those people didn’t have time for us. We could get little information from them via their secretaries or some meeting that was planned meticulously. And in that meeting only 1 or 2 of our people could be present, to make sure they didn’t spent too much time. Getting specs or finding out what to build and build the right thing was not an easy task. Our business analysts had their work cut out for them but did a very good job with the resources they had. Getting feedback from them was even more difficult. Especially getting it fast so we could change the product quickly. Despite all that, we were able to deliver a working product to all clients. This blogpost is a reflection on what I think I did well, what didn’t do well and what I would have changed if could have done it over.

Sprinkling chaos

The day isn’t even half and twice I’ve caused chaos!

This morning I asked the analyst in my team why I got to state A instead of state B as I expected. She was also very confused and embarked on a quest!
First we discussed it among ourselves and decided we didn’t know enough and so we went to one of the developers.
We explained him what was going on and after a short while he just said “I don’t know, ask the other developer.”. And so we did! We started talking to him and saw him panic. He made that change! We we’re on the right track. So after quizzing him on WHY he made the change it turned out that it was never documented. He was told to do it in some call and he just executed it.
Now the analyst got a bit annoyed. She’s supposed to know these kind of changes. She’s the one in charge of keeping the documents up to date. These documents we provide the client so they know how to use the product. So she started grilling the developer on who told him, when and why?

In the rear-view mirror

I’m a consultant, and my project ran at its end. It’s been very nice and I’ve learned so many things. I started out as a very junior tester but my colleague got me up to speed pretty fast. I gave shape to my own testing ideas, became the sole tester and even test lead.

This is not a bug!

I’ve been in discussions before whether something is a bug or not numerous times. To me this can be frustrating, because I believe this change will improve the product and should be done anyway.

Feel the testing!

Testing is often regarded as a black/white field. Something is correct or something is wrong. But any practiced tester will know that there’s much more to it than that. There are always things that are not in the analysis and even things that are in the analysis might feel strange to you.

What do you do?

– “I’m a tester.”
*Nods*
I take from their reaction they know what I said, but have no idea what I do.
– “Most of the times I find defects in software, written by others.”
I see that they now have some idea of what I do, but are still left with questions. So I continue:
– “I try to make sure that when we deliver a product, that it actually helps the users. No-one needs more software, they want a solution for their problem.”
“Ow yeah! At my job I have this software that doesn’t help me at all!”
Lots of times they’ve experienced bad software before. Telling them that I’m working to help the user, helps them understand why my job is valuable.

Automation, not always self-evident!

Lots of companies now request automation. And although automation is a good thing, there is a place and time to implement it. When you’re trying to automate an application that’s still prone to have big changes, you’ll find yourself doing a lot of rework. It will make it a lot harder to write tests that only fail when the application is wrong and not the test.