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?

I never intended to make it this big of a deal, I just got confused and asked for more information.

Afbeeldingsresultaat voor chaos

A bit later I was wondering if there might be a problem with indicating which fields have an error. If there was maybe a consistent way we could show the field names instead of the logical names, who can be weird sometimes.
This sparked a pair programming/investigating between two developers to see if there even was a possible solution to my seemingly easy question.

They came up with 3 possible solutions and decided to implement one quick one, and ask the PO later on which will be the permanent one.

I sprinkle chaos in my team.

Not only do I sprinkle chaos but also help my team deal with it.
The analyst was getting lost in how this situation came to be. The developer got a feeling he got the blame for doing his best. The situation was escalating  a bit.
I made clear we weren’t looking for somebody to blame, we just want the right information to move forward and prevent this situations. The analyst also needed some help not getting lost in the past, and focus deal with the current situation instead.

Seeing the developers move so easily to a pair session was nice to see, but also distracted them from their daily tasks. I let them work for a while but tried to see if I couldn’t help or maybe should create a task, that we could plan in later instead. So this is what we did once we knew how to deal with the issue.

Being a tester isn’t only about finding issues. It’s about helping your team in any way you can. Even if it’s helping the conversation between to people or keeping them from getting lost in a task.

Advertisements

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.

Continue reading “In the rear-view mirror”

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.

Continue reading “What do you do?”

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. Continue reading “Automation, not always self-evident!”

My spyglass into the code

As a tester you don’t always have access to the code of your application. Sometimes this doesn’t matter, but it can also be very useful. I can’t keep up with the developers writing code, but I do have a tool that allows me to use the code to my advantage.

That tool is the ‘AppMon’ by Dynatrace. This application monitoring tool injects code in the code-base and records all the executed code. This data can then be displayed and searched. As a tester, this provides you with a massive amount of information and a spyglass into the code.

disclaimer: This is not a sales pitch. This is just my appreciation for this tool in form of a blogpost. There might be similar tools out there that do the same.

Continue reading “My spyglass into the code”