How To Make Your Team Hate You #3

I was thinking about the colleagues I’ve legitimately despised (and it’s not just my opinion), and most of them have something in common: they have either been promoted, or told they will get promoted if they prove themselves, resulting in a change of behaviour. So here is story number 3, and hopefully the last one since I don’t have any more drafted up.

The Situation

I was once on a project where I was the only software tester. Usually, when it’s a proper project where it is going to span 3 months or more, then we would have at least 2 testers assigned.

I was well excited to show that I could handle this responsibility. The project went well, and I was well proud. That project was actually a prerequisite for something bigger, and yet again, I was looking forward to the challenge of the follow-on project.

Collectively, both projects were going to be a replacement for part of our software, but it was going to be phased over time. Therefore, it was important that the old version still worked.

So I looked at what the current system did and wrote all the features down. I then spent ages looking through all the Test Cases, comparing these to the features that I documented. Then I had to write the Test Cases that were missing. This probably took around a month of preparation.

Since the new version needed to do what the old one did, but might have done it in a different way, I basically had to duplicate every test, then start changing the steps accordingly.

Having this 100% complete test coverage worked well, and I knew people would be thankful for it in the future. Anytime a feature is changed, you know there are tests that you can run for your manual regression tests. I think every tester has been annoyed at some point; when they think a test should exist, but it doesn’t, so they have to begrudgingly write it.

I’ve done the work for them. I don’t think any other area of the system had this level of test coverage. No one can be annoyed about this can they?

As we moved onto the second project, I was told another Tester, Barbara was joining the team. I’m not sure if I was told explicitly, or if I just heard rumours, but I’m pretty sure I knew it was the case that – if Barbara did well on the project, then she would be promoted to Test Lead. Based on my performance over the years, and based on the project I had just finished, I think it should have been obvious to promote me to Test Lead. Maybe I was slightly annoyed, but I don’t think that had any affect on what happened next…

The Conflict

So Barbara joins the team and looks at the test cases. She wasn’t happy. Despite having that 100% test coverage, the tests were “too granular”. She says that when it comes to testing a particular feature, we would end up adding maybe 10-20 tests from my pack. She only wanted to run 1 or 2.

So she starts complaining at me, telling me I’ve wasted my time and I need to rewrite them. She likes the idea of “end-to-end tests” where one test actually tests several features and could describe what a user would do over a 5 minute period.

For example, I may have written a test that describes how to create a document, then another test how to print a document, then another test on how to email a document.

Her way of testing would be to include all the instructions for these 3 features and put them in one test – since a user may log in, create a document, email it to someone, then print a copy out for themselves.

I argued that my way is better, because if there is a bug involving email, you can just pick out the short test involving email. I’d be annoyed if I had to test printing it when it has nothing to do with the email bug fix.

“But that’s not how we did it in my old team!”

Yeah, but you aren’t in your old team. You’ve joined this one, and this is our process.

She used this statement multiple times about different aspects of how we work. I kept on explaining how if we work “agile”, we are supposed to come up with a process that suits us, and agree as a team. This process suited us, or at least it worked perfectly well before she joined our team.

Yet she comes in, kicks off a massive fuss to try and put her stamp on the team, and bypasses the correct channels for these decisions; which would have been the Retrospectives. I would have been happy to debate it in a meeting, rather than her dictating what I should do in front of everyone.

What Barbara did next was – run off to her manager, who happened to be my manager as well. But because my relationship with my manager was simply a professional one, and Barbara was very chummy with her, then our manager instantly backed Barbara.

So then I had to plan out which features made sense to use after each other. I spent 3 or 4 days planning this out. I spent more days writing them. I only wrote about 7. How many test cases did she write?

Zero.

Didn’t practice what she preached.

I was fuming.

When it came to testing the new features, she often volunteered to test the easier items, and gave me the harder items. I didn’t mind, because if she wasn’t on the project, I would have just done them all anyway.

What was infuriating, was that the next day, she would chat some nonsense about how she was too busy so didn’t have time to test it, so then asked me to test it instead. So I’d end up doing all the work. It’s just that it would take longer because I’d finish my work and have nothing to do, then the next day, I’d have to do her work that she was supposed to do. So the result was that we had 1 extra tester in the team, but productivity had halved.

She did this for weeks. It wasn’t a one off. Often, I’d look at her monitor and saw she was sending personal emails, doing online shopping, or just looking at news.

Then when it came to the stand-ups, where we stated to the rest of the team what we had accomplished; she then claimed that she did the work.

I was fuming. How could she say that when I was standing there with her? It’s plagiarism, and absolute lies. I complained to my manager. She refused to do anything. I was so tempted to walk out.

I’d never had that feeling of not wanting to go to work before, but some days I just didn’t want to go. I actually started looking for new jobs.

Sometimes when Barbara was away from her desk, I’d be ranting to my team. We were a close bunch on the initial project, but it just didn’t feel the same way. Soon I was brought into a meeting with the project manager who seemed to suggest I should apologise and try and get on.

I don’t get it. We were all close and worked well together. We delivered a project successfully on time. A new team member joins. Testing productivity is halved. There’s massive friction. Who do you think is the problem? You could easily verify my claim that she wasn’t doing the work. The test case runs are audited. My name would be on every one.

It seemed that Barbara had just sweet-talked everyone and they were determined to promote her regardless. As a Test Lead, you are supposed to have testing skills, people-skills and some management skills. Barbara wasn’t showing any of it. She was refusing to run test cases and she was causing friction. Productivity of the testing side was lower than when it was just me on my own.

Epilogue

So what happened in the end? Well, I was a bit unsure what I wanted in my career. I initially wanted to move up the ranks as a Tester, but it wasn’t happening. I did get the craving to be a Developer, and considered becoming an Automated Tester. I requested a change of role to a Developer since the Automated Tester role didn’t exist in the company. I’d be in the same department, but I knew I’d switch teams so would be away from Barbara. I just had to put up with another couple of months working with someone I despised.

I did get my internal move in the end. Barbara got her undeserved promotion. Years later she got made redundant. Better late than never.

For more in the series, see: How To Make Your Team Hate You #1 and How To Make Your Team Hate You #2

Shelving, failed restart, then restarting a project

When we entered lockdown, there was a small project that was identified as urgent, and very helpful to our users due to the current situation. Originally, they estimated a simple change. So we make a change to one file. When testing it, we realise it didn’t send the information in the outbound messages to a third party. So we made further changes which were a few day’s work.

We then had a meeting with a few different types of managers. They wanted to know about our progress and they wanted estimates to finish the project. I thought it would only take a few weeks to test. However the Tester said it would take 3 months which I think he was just being extreme to cover his back. He did explain it was more complex than I had thought, but still – it was clearly over exaggerated. The Managers didn’t like the idea of having a Tester tied up for that long, so the project went “on hold”.

Months later, I was invited to a meeting to restart the project. A Project Manager was ranting that there was a financial incentive to get the feature out by the end of the year (2020), but if we deliver it late, then we miss the bonus. Even if we restarted straight away, we had left it too late – there was no way the testing could get done, and deploy in time to meet such a deadline.

The Tester stressed that my solution is just a prototype and needs to be reworked. In reality, it was fine as far as I was aware, but he was just buying extra time if we needed it. It was the Testing side of things that needed the focus. We needed to test these extra configurations, but a prerequisite was that we needed to understand how they were set-up.

I couldn’t really do much work until the Tester had done this extra testing to see if my solution covers all the different configurations he had come up with. However, the Tester was busy with some other work so he couldn’t do that for a few weeks. A few weeks later, a Product Manager messages me to ask when the project started. I delivered the bad news: “It hasn’t”.

A few more weeks go by, and we have a meeting with a new Project Manager. So we discussed the story so far with him. It was also announced that the Tester (who has all the knowledge about this project) would only be partially available – so needs to pass on his knowledge to another Tester.

Another week or so goes by and another meeting was arranged. We have a new Project Manager.

Ridiculous.

She starts making all kinds of demands about having all the usual Agile process. (User Stories with estimates etc). However, it’s a weird project because we have basically done the development and we just need to test. All this process seemed a bit overkill to us.

We had another “Project Kick-Off” meeting, and the Tester asked the Software Architect about setting up all these different configurations. The Architect then said the Tester had misunderstood and there was actually only 1 configuration.

This meant the testing time had been drastically slashed – you know; the exact reason why the project was delayed in the first place. So all these delays, extra meetings talking about the delay, all the meetings to rearrange the project; none of them actually needed to happen. We could have just completed the project when it was first assigned, additionally collecting that financial bonus.

Software Testing – Can developers test?

A software tester created a presentation about “the role of a tester”, and discussed whether “software developers” make good “software testers”. I thought the presentation was a bit confusing, because in some parts it sounded like she was saying they can, but in other places, it sounded like a categorical NO.

I found this quote recently from Ron Gilbert, creator of computer games like Monkey Island and Thimbleweed Park. It covers “game development” specifically:

Don’t believe the myth that programmers can test their own code. They can’t. Programmers will test for all the conditions they can imagine, but a good tester will imagine many many more and players will try things programmers never even considered. Knowledge of their code is the achilles heel of programmers. I’ve had code I was 100% sure was rock solid, only to have one of our testers reduce me to tears. A good tester excels at poking your code in places you never considered. I’m not talking about your unit tested sort routine, I’m talking about complex puzzle logic and odd UI uses. It’s the stuff unit tests will never catch, but a good tester will. Testers are the unsung heroes of your team, treat them very well.
Ron Gilbert – https://grumpygamer.com/delores_dev

This is the way I see it:

There’s the concept of being “close to the code”. So the developer that wrote the code will test exactly how they implemented it – and not test the cases they missed; because they never thought of those scenarios in the first place.

A tester inside the company could be influenced by their relationship with the developer; have some unconscious bias about not wanting to find a flaw in their code because they don’t want to upset them.

A tester for a third-party has no connection to the code or the staff at the company. They can test it without any bias. Finding all bugs is a good thing, because it enhances their reputation and should help with repeat custom. This is a good rationale for why some companies choose to outsource the Testing aspect entirely.

When I have worked in small teams and there is a testing backlog, sometimes the developers will help out with the testing, but they won’t test their own work; they will make sure it was done by another developer. This helps alleviate the above point slightly.

I have heard many developers say “they aren’t testers”, “I don’t know how to test” etc and for the most part; I think that’s nonsense. If you understand code and how to use software, then you understand how to test it. Sometimes it is directly transferable skills, but I think sometimes you need to take a step back, “put on another hat” and try to look at it from another perspective. For example, you then think “If I was a user, what would I want to do?”, “if I hated the company and wanted to find a bug in the code, no matter what it is, what would I try?”. You poke it in different ways. I think if you fail in the skill of being able to “put on a different hat”, then Ron Gilbert is 100% correct.

Personally, I have experience as a software tester, and as a developer. I do think I test my own code better than many other developers – ones without that experience. However, I don’t think I test as well as I used to when I was testing someone else’s code. It mainly comes down to the point I mentioned earlier – the fact that you only test what you know you have implemented and don’t test the things you haven’t. I mean, if you did think of it earlier, then you would have implemented it.

How To Make Your Team Hate You #2

We were in a newly formed team, and Rob was a newly promoted Test Manager. As developers, we were planning on tidying up the code base, formatting the code consistently, and removing unused code.

There wasn’t any real testing to do, given the code was unused, but Rob insisted we spend time investigating how to test the code.

It didn’t make sense – how can you test some code that isn’t used? Unless you prove it somehow is used, of course. But if the developer could tell the tester how to prove it is used, then the developer would know it is used, and wouldn’t remove it.

For the actual, real, development work, Rob demanded that we come up with a full test plan for every planned piece of work before we are allowed to make any code changes.

The thing is, even though I know the overall aim and could explain some test scenarios up front, I will always suggest more tests after I make the code changes. After I have made the changes, I am familiar with other areas of the system it impacted, or extra changes I made to refactor the code. So it only would be a temporary plan anyway.

Once we made that point, Rob then said we should analyse the code, plan out what code changes we would make, including refactoring, and document them. When all items are documented, we could then start work.

Who agreed in the team? No one. Not even other testers. Yet, he then runs off to higher ranking managers and persuades them that it is a good idea. I think they were just good friends with him, so they backed him.

We ended up spending ages working out what we were gonna change, but then not actually do it; because we had to plan every item first.

When the time came to actually implementing our plan, you then had to spend time re-familiarising with the solution and then verifying if the proposed solution was actually accurate. The person that did the planning may not be the person to actually implement it.

We ended up being 2 months into the project and not a single line of code was changed. When we started doing the work, the “familiarising” process just annoyed people. From the start, we had stated that the entire process was dum, we were annoyed at the extended planning time, then the actual development stage just reinforced how dumb the entire thing was.

I don’t know if anything happened behind the scenes, but Rob was moved off our team at this point, and it felt like a huge weight off our shoulders.

I don’t know what Rob aimed to achieve with his idea. I think he thought it was a process that enforced quality, but he was unanimously told it was a bad idea, but yet fought to get it implemented. Surely if the team is fighting against it, then dictating that they implement it is just going to cause so much friction – that your position is going to be untenable. And it was.

The lesson here is that if you do get promoted, make sure it doesn’t go to your head. Yeah, you have to manage people, but having a new fancy job title doesn’t mean you have to go wild. You are working with people. You are still working with your old colleagues. Treat them with respect and be more understanding. I think a lot of managers gain respect by being nice and leading by example.

Report API fail

A tester says they are running a Test Case where they need to generate a report using our software. This report utilises a third-party service. The report fails to generate.

There should be errors displayed when you view the details, but it’s completely blank. So if they have correct data, then it’s a bug because it doesn’t work. If they don’t have correct data, then it’s a bug because it doesn’t tell the user what the problem is. It’s a bug either way.

Becky, a Senior tester:

Asks him if he has the correct data. Completely misses the point.
Then she posts a follow-up question asking him if he has gone directly to the third-party website to get the information. Completely misses the point.

No, Becky, the functionality is that our software contacts the third party API to retrieve this information. Manually going to the website and filling a form out by hand isn’t helpful, or acceptable. It isn’t going to make the test case pass is it?

“ok, we will pass the test because the website works. Nothing to worry about.”
Becky’s mind

Sometimes I think she tries to be dumb on purpose.

User has been deleted!

In previous blogs, I’ve told a few stories about how bad a software tester, Becky, is at communicating. Sometimes, it seems like she is trolling. Here is another story:

“My user has been deleted when I clicked the refresh button, how do I undo?”.
Becky

Well, I think you should have panicked and logged a high priority bug if that was the case.

There’s obviously more to this than she is stating. Your user doesn’t mysteriously vanish by clicking a button which says something other than “Delete”. What makes her think she can undo this action? Why does she think this is normal?

I replied, asking her for more information: What was she trying to do? What does she remember clicking before it happened?

Becky ignores my requests and directs her messages to a select few software testers.

What are the testers going to do? If there’s a serious bug, it needs to go to a developer to investigate, and promptly!

Why was she ignorant of my attempt to help? It made me think if she doubted what she was writing, and deep-down; she knew her user hadn’t been deleted afterall.

I decided to play around with the software and click some random buttons, but I noticed something peculiar pretty quickly.

It turns out there was a bug in the displayed list of users. Her user existed, it just didn’t show it unless you selected a different filter button; then reselect the initial filter.

She didn’t bother logging a bug. It’s literally her job as a software tester.

Becky arranging testing

“for those that will be helping out with the Phase 2 testing, the suite is here…”
Becky

I think we have around 5 testers in the team, and only 1 tester responded to Becky. This testing seemed urgent and the fact that she said “for those that will be helping” – this made out it was the testers, plus some other non-testers as volunteers.

As a developer, you assume you aren’t needed – because you’re a developer. But if a tester says their testing is urgent and they need help, then they may request volunteers. It was the first I’d heard of this, and it seemed weird that only 2 people were actually testing.

I questioned the statement, and apparently Becky wanted testers AND developers to volunteer. Why didn’t she say something? She managed to make it sound like people had already been told if they were doing it.

She is so bad at communicating.

Maybe that’s why the Testers weren’t even testing it.

Becky is a Senior Tester and I remember our Team Lead saying he was going to give her more responsibility because she wanted to progress her career. Well, she can’t even manage to get Testers assigned to do some software testing, so what hope do we have?

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?

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.

How To Make Your Team Hate You #1

When I was a Tester, I was on an important project and was pushing the time. It wasn’t my fault, it was just the nature of the project, the nature of the testing, and the fixed deadline. I always knew it would be a tight schedule. I didn’t want to sacrifice quality though and I knew the only way I could get it out in time if everything just worked, with no bugs and technical problems, and I needed 100% concentration to prove it.

I get interrupted by the newly promoted Test Lead. He sits there for several minutes berating me for the slow progress and starts reeling off a speech about how important the project was to the company. I kept on telling him I already understood and his speech was wasting my time and delaying me further. Obviously in addition to demoralising me.

After he finally left, the Lead Developer on my team exclaimed “who the hell does he think he is, talking to you like that?”

I’d never seen this developer angry before. He always had a calm demeanor. But he was furious.

The next day, the Test Leads line manager pulled me into a meeting and said the matter had been dealt with and that will never happen again. I then realised the Lead Developer must have reported him.