Who changed the config?

Last week, a tester, Paul posted a message asking if they could change the configuration on one of the test environments. They were switching the locale from England to Scotland.

A tester, Becky then makes a fuss saying “We can’t change England to Scotland”.

Paul replies “Too late! I have now finished my testing, shall I change it back to England?”

Becky replies “No that’s fine…..I needed to understand what you were testing but if you’ve already done it then there’s nothing else to do.”

One week later:

Becky: “Is there a reason why the test environment is set to Scotland? This was previously set to England”.

Erm, yeah. You told them not to change it, but they already had. Then you told them not to change it back, so it’s still set to Scotland.

U-Turns

On the back of “Testing and Developer Equality”, Colin highlighted some minor problems in the code base and made a statement of “Any Tester should be comfortable picking up these items and writing code to fix it”.

One of the Testers spoke up and said “Not all Testers are comfortable, I for one have no interest in coding. Please don’t ask me to code”.

Then Colin quickly u-turned and said “I never said all Testers can code, but the ones that are interested in learning can pick these up”.

That’s not what you said Colin.

U-Turn #2

A Tester asked for help diagnosing an issue he found, and asked who could debug the problem on the Test Environment. Colin replied, and made a statement about having to install some debugging tools and how it’s going to be difficult because it’s a server-side problem.

Many developers have made comments in the past on how it’s basically impossible for us to debug server-side issues with our infrastructure (we can obviously run the client and server locally on our own computers, but sometimes problems are with specific data on the Test Environments).

Recently, I tried it to see what the problem actually is, and it worked perfectly fine. No idea where this myth came from, but it’s been passed on for years. You don’t actually need to debug the actual server. You can run the server locally as long as it is the same version. You just need to point towards the Test Environment’s databases rather than your own.

So after Colin’s statement, I described my findings about debugging the server and data.

Colin then responded “I never said that you cannot debug the server”.

I knew he was talking nonsense. He was definitely implying you cannot debug the server. I also remember he said it a few weeks prior. I searched Slack for his post history and I found it.

“If server side, then we have to try to recreate the issue in our own environment.”
Colin

I don’t get why people can’t just seem to admit they were wrong and be grateful for your information. I normally write something like “oops, I was mistaken” and then choose a funny emoji like 😖or 😜

Pair Programming With Beavis

Beavis is a software engineer that loves making excuses to avoid work. Beavis had a bug to fix in the same area that his previous fix was for. For his previous change he did ask:

“It’s a fix for the current release, so not sure if it goes directly in, or we Dev test before-hand.”

When developers say things like this, I do wonder how and when they test their changes. Do they just change a few lines, and “throw it over the fence” to the testers? Why does it matter what release it is for? “Oh it is for an urgent release? I won’t test it then”.

I don’t think he manually tested it, or even understood the overall context of his changes, but he did eventually add some unit tests which were logical and I believed would prove his fix would work.

The problem is now he has a new bug fix to do, and he still doesn’t understand the context. I was free so I was asked to help him.

For this change, we specifically needed to use a Virtual Machine. We were supposed to set them up a month ago, and Beavis had, crazily, logged 20 hours against this work on his timesheet.

Me: “Have you set up your VM?”

Beavis: “No”

Me: “OK, well that is going to take you the full day. So download the required programs and check out our source code”

I didn’t really expect it to take the full day. Maybe half a day, with a bit more time if there were problems somehow. I wanted to get a head start looking at the code so I had a better chance of training him later. I also thought if I allow him a day, at least it will lower the chances he is going to start coming up with excuses.

I began to look into the problem whilst Beavis was setting up his VM. The next day, Beavis doesn’t show up. The next day, Beavis returned to work but said he was having network/proxy issues so could not download the required software – so was stuck.

It took me a lot longer than expected, but even allowing Beavis 2 extra days, he still didn’t get ready. So I did it all myself.

Monitor Request

The work laptop I have has a really poor quality screen. You would think when you work 7.5 hours on a computer, then you should get the best equipment possible. Anything you can do to increase staff happiness and productivity should be an obvious investment.

I put up with it for months, but I felt it was destroying my eyesight, so I had to do something about it.

My manager told me I can request a monitor from our IT department, to be delivered to my house. “Perfect”, I thought. I logged the ticket.

Two weeks later, I get fed up, and hook up the laptop to my living room TV. I sit on the sofa now. It’s actually comfortable. I go to the IT Portal to close my ticket, but it’s already closed. Must be rejected, even though it would have been nice for them to write a comment.

Another four weeks go by. I get an email saying my monitor will be delivered. I don’t want it but it’s too late now.

I wondered if they would finally get some decent equipment so I was still quite excited to accept it.

Nah, it’s just a standard 20 inch monitor.

Testing and Developer Equality

I think it is possible to have an “us and them” kind of attitude between the developers and testers. You are supposed to work together to a common goal; deliver quality software.

Since testers have the responsibility of making the final call if the work is good or not, and can send it back to the Developer, then there can be some resentment here. I have felt that a bit when I was a Tester, but it’s rare to witness events like that.

There was a time when it was announced that the Software Tester job title was changing to sound more important, and recently, there has been rumours that my employer is considering making Developers and Testers: “Engineers”. I don’t understand what a blanket term like that even achieves. Surely it is a nightmare for managers to sort out projects in the future. New managers may end up trying to put several Testers in a team together because all they see on a spreadsheet are several “Engineers”.

Surely it makes recruitment harder when you are advertising for “Engineers” and it isn’t clear what job you are applying for.

Some Testers can write code, and they will create Automated Test scripts, or some helpful application. Not all Testers can write code, or have even a slight interest in writing code.

I think it’s a case of managers trying to fix a problem that doesn’t even exist. There have been a few Testers that were vocal that they don’t want to be called Engineers. They are Testers and are proud of it. They feel that being called Engineers will come with the expectation that they have to be able to code and they don’t want that. I’m sure some Testers will be happy with the proposed change, but I think most people will agree it is a stupid change.

I do wonder who came up with the idea? Why change something if there isn’t a problem? What problem is this trying to address?

Merging for 3 days

There was a project in a code branch that needed merging in for the release. Colin volunteers to do it. I expected that it would take him half a day, depending on if there are conflicts to resolve which can be quite tricky.

3 days later, he sends it for review. A couple of developers reviewed it and left him 17 comments of “is this your change?”

Colin responds to them “No I’ll remove it.”

How has this happened? How can he mess it up so bad?

There was a project that I worked on where we delivered it in two stages. We merged our changes in, but there was one feature where we discovered a problem so we reverted one file.

Another team had merged from the master branch into their project branch to take our original changes. When they merged their project branch into master, they wrongly resolved the conflict and reintroduced the problematic change in that one file.

No idea what Colin did though, it’s almost like he had merged a different branch into his branch then had merged it to master. I’m out of theories. It took him 3 days and he had clearly messed it up.

Testing found 4 bugs with the project (which may be original bugs missed in the original testing before it got merged in). How many have they not found? That’s what worries me.

Third party update

There was a bug in some third party software. If you upgrade to the latest version of the driver, then attempting to configure a hardware device to use with our software will fail.

Me: “Is it a problem for live users? “Surely we need to tell our Support team”.

Test Lead: “We would have probably heard by now. Some users are unlikely to update.”

Me: “Erm, all it takes is one user to upgrade, or what about a new user? They are guaranteed to configure it for the first time”

I was right and the issue got escalated as high priority.

I don’t get what testers are thinking these days.

“Working Closely”

My manager calls me.

Manager: “Do you know Andy?”

Me: “Yes, he is one of my best friends”

Manager: “Great, because you will be working closely with him.”

Me: “Brilliant news. So does he know about it? How do we go about splitting up the work; is it a big project?”

Manager: “Well, simple answer; you aren’t splitting it; you are doing it all.”

Me: “Oh.”

How is that working closely? After I got more information, it turns out all I was doing is merging some of Andy’s work into another code branch. Andy could have just done it. Complete hype for nothing.

I Agree

There’s one guy in my team that always wants to portray himself positively. So he loves talking, and, in my opinion, he basically keeps taking credit for other people’s ideas; or at least wants people to think he had some contribution to them.

So here are some clichéd phrases that he reels off in every meeting:

When someone says something good:

“I was just about to say that”
“I agree with that”
“I was just thinking that”

If he thinks someone knows more than him:

“We need to touch base”
“We need to arrange a catch-up so we are on the same page”

If he says something stupid:

“I’m only asking the question for everyone’s benefit”
“I just wanted to call it out so the decision is documented”

Becky did a similar thing the other day:

Becky: “a menu option disappears until you log out and back in again. Do you think that is a feature?”

Sean: “Sounds like a bug”

Becky: “Yeah, that’s what I was thinking”

Sean: “If we introduced it, this will need to be fixed before the release goes out”

Becky: “Yeah, that’s what I was thinking”

No, you were thinking it was a feature like an idiot.

It turns out she was just logging in with a different user profile. So the feature wasn’t there to begin with on the first profile.

It annoys me when people just pretend to agree. If you don’t understand something, then someone needs to explain it to you more. In the first example, he does ask questions to get the information, but he also claims he agrees in an unreasonable number of situations. If someone comes up with an awesome idea, let them have their moment of glory rather than using phrases like “I was just about to say that”; because that devalues their contribution.

Awkward Call With The Customer

I get invited to a call with a customer about an important enhancement. It’s about an area of the system I have very basic knowledge of. The call is in 30 minutes so there’s no time to read up on anything.

If it’s an internal call, then it can be embarrassing but it’s easy to explain the situation. For an external call; then as a company, we seem like idiots.

I tell my manager that there is only one developer that knows about it; Bruce. Luckily my manager contacts him and he agrees to come onto the call. I’m still required for some reason.

I still anticipated it would be really awkward. The customer says, “can we all introduce ourselves”. So they all take turns.

“I’m Sharon, lead customer representative in Team A.”

“I am Bruce, I was the Lead Developer on the original project and have been involved in related project X”.

Everyone has great credentials. It eventually gets to me. I don’t have a fancy job title or any related credentials to this call.

<awkwardly>“I am A developer”
Me

Luckily, the customer did the majority of the talking, and Bruce chipped in to deny/challenge the occasional suggestion. I would have been doomed if I didn’t manage to get Bruce involved. He saved the company reputation there.

Surely, we knew about this arranged call days ago. How did we get into this situation? It’s another management failure.