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.

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.

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.

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.

Crisis averted

In times of crisis, our first reaction is to start looking for a guilty person. This is a normal reaction, but not a constructive one. But what should we do when a crisis does come up?

Dehuminization of a bug

Bugs don’t just magically appear. They are there because of a reason. Someone, somewhere made a mistake, and now it’s a problem. Making sure these mistakes aren’t made, is the responsibility of the entire team.

If a bug does come out, it means someone failed to do their job correctly.

Dear developer,

It’s me the tester of your, our, project. I’m writing you this letter to explain what I’m doing. Why I’m an asset to the project and how I can help you!