Category: Testing

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?

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

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. So here is story number 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.

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 lead by example and gain respect by being nice.

New Tester

I didn’t think we really needed a tester, but months ago we put in a request for one. Now we finally have a new Automated Tester!

He is off to an amazing start…an amazingly bad start.

He did a bit of manual testing to understand what we have so far. He logged two bugs which are probably the same issue. On the stand-up, he says they are “minor”, so I assumed minor cosmetic issues.

When I encountered the issues, I would categorise them as major cosmetic. One of them was that the menu panel appears at the opposite side of the screen! How does that even happen? The second issue was that it sometimes didn’t appear at all! 

The control is completely broken then. I’d say it’s pretty urgent given how little features we have.

He then starts writing automated tests, and the first one he submitted seemed to be backwards. I told him the test didn’t make sense, he kept on saying “it’s just a sample”. I didn’t understand what he meant, it should be a valid test. It was on the lines of :

GIVEN I navigate to the LogIn Screen
AND I enter valid credentials
WHEN I click Log In
THEN I am taken to the Home Page

although what he wrote was

GIVEN I navigate to the Home Page
AND I enter valid credentials
WHEN I click Log In
THEN I am taken to the LogIn Screen

I told him the page names were the wrong way around. He was demanding I let him check it in because the test passes; it is fine. I told him if that test passes, I don’t trust the framework.

He then explains that the test finds the title of the webpage is “Home Page”, then you are redirected to the LogIn Screen. After you type your credentials and click Log In, you are taken to the Home Page. However, the check doesn’t wait for the page to load, so at the time it checks, it finds “Log In Screen”.

So the test is crap basically, but instead of fixing it, he specifies the wrong page titles to get the test to pass. The functionality is correct, but the test is Invalid but Passes.

I eventually (reluctantly) agree to let him check it in anyway on the promise that when he adds more tests, he also fixes that. A week or so later, he sends an update. You will definitely think I’m making these stories up.

GIVEN I navigate to the Home Page
AND I enter valid credentials
WHEN I click Log In
THEN I am taken to the Home Page
WHEN I click logout
THEN I am taken to the Home Page

Yeah, that’s right, we are always on the Home Page no matter what we do. How can that pass this time? I’m out of ideas.

Enforcing The Quality Process

If you find a bug, you are supposed to log it. Simple logic. However, people get annoyed when they log a bug, then the developer just tells them it’s a simple configuration option they have missed, or they don’t even have the latest version. It can take time filling in the Bug report, and it’s annoying when you have to almost instantly close it.

So then you get the attitude where people will rather email the problems, and hold off logging it until a developer confirms that it’s probably a valid bug. If the developer doesn’t actively check, then bugs can go unreported; which can be a disaster.

The other day, a Senior Tester posts a massive stack-trace in Slack. I have a quick look and realise it is a bug. As I was about to reply, another Senior Tester, (who is about to be promoted into some kind of Quality Process Manager or some nonsense; or maybe that is a rumour), tells him to repost it on Microsoft Teams. But not just one post, she wants it posted across two channels for “maximum reach”.

Or maybe maximum annoyance.

It’s really dumb, we have this process, and someone that is supposed to enforce the process – and definitely someone that will be enforcing the process in her new role – is coming out with nonsense like posting in informal channels.

If there is a Bug, then log it. It can always be closed with a valid explanation; which can help others in the future if the same problem crops up again.

Doing Admin

Beavis, a software developer, was supposed to be helping out running manual tests since the Testers were behind on their work. That day, he was working at home and posts on Slack that he has “network issues” so was unable to test. He could have picked up some development work instead, but he didn’t bother.

So for his stand-up update, he says he was just doing “general admin” which I reckon meant he was chilling out at home.

A Tester explained to him that when they work at home, they remote onto their work PC, then connect to the test system from there. It’s a bit of a workaround but it’s what everyone does.

Unhappy with this workaround, Beavis decides to log a ticket with our IT Helpdesk.

A few days later, Beavis is supposed to be helping out the Testers, but is working from home again. Yet again, he posts on Slack that there are still “network issues”. A Manager challenges him on it, and he says he has logged a ticket, but it hasn’t been addressed – so he can’t help. The Manager tells him to remote onto his work PC, which is a known workaround.

The next day, for his stand-up update, he said he ended up doing “general admin” again like tidying up his C drive, and he was also doing “personal development”. So completely defying the Manager and other Tester’s advice.

He isn’t the first person to use the “doing admin” excuse. It’s hilarious when you think about it. How can you claim you spent 7.5 hours creating new folders, or sending files to the recycle bin? Even more ridiculous when you have already made that claim in the days prior.

Playing Dumb

Derek always annoyed me when he would play dumb when doing non-programming tasks. So if he was helping Testers by running test cases – they would tell him to open a test case, and he would be like “what software do I use?”, “what do I click now?”, “do I click the Pass button when I’ve finished?”

It just wastes time and frustrates people. I always thought he was being as awkward as possible so they would just tell him not to bother. If he asks all those questions, then it’s just gonna waste a tester’s time. If they are answering questions, then it means they aren’t running test cases. The idea of a developer helping out means there are two people running test cases. But an awkward developer just means there is a developer slowly running test cases whilst supervised by a tester who could have just done the job quickly.

I’m introducing a new character, Beavis; because he always acts dumb, or at least appears oblivious. Also, he has a very Beavis-like laugh.

Beavis was doing the exact same technique. I heard him ask many dumb questions like that. Later, he calls me over to help set something up. I tell him his account doesn’t have enough permissions.

So he logs in with the admin user, goes to the configuration module and then says:

“how do I find my user?”

“click the Find button”

“where is that?”

“In the menu, first button”

he clicks it. A dialog appears. “How do I then find my user? Do I just type in my name?”

“No, you have to type Pi to 10 decimal places!”

I didn’t really say that, but it was hard to keep calm with the questions that are just wasting my time.

He then says “sorry, I’ve never used this program before”. Even though that was clearly a lie.

Beavis and Butthead

I know he hasn’t used it much because he used to work on a completely different software product, but he has used it and was helping a Junior set it up the very next day. But when you have 20+ years of experience in the software industry, how can you not be comfortable using basic features? Many features are intuitive. If you wanted to find some text, it doesn’t matter if it is Internet Explorer, Microsoft Word, Notepad, OneNote, Visual Studio; you would always press Ctrl+F. Want to Save? Look for a “Floppy Disk” icon, or the word “Save”.

Full Regression

Several months ago, a project was completed (let’s call it Project X) that must have contained the biggest impact to our software. What I mean is that the scope impacted a lot of features, and therefore to sign it off, the testers ran an insane amount of regression tests. The Project X team ended up running these tests with the help of other teams, and many hours of overtime was needed.

A release was being planned that involved more bug fixes than usual. I think one of the Test Managers had suggested that we run a full regression test to ensure the changes made by Project X hadn’t been effected. Marcus, a tester involved in Project X stated that this was an “unreasonable request, and we need to do a more focussed, targeted test”.

The next day, a Test Manager came up to Marcus and said she had asked someone to give estimates of a full regression and she had been quoted 6 weeks. She said it was absurd and wanted Marcus to confirm it. Marcus stated once more that he had already highlighted it was an unreasonable ask. He explained that she is requesting that 4 people run the tests over a two week period, when the original team had three weeks and around 20 people were involved. This is why Marcus rejected the proposal in the first place.

Another day passes, and another Test Manager announces that, after much debate – running a full regression isn’t feasible, so they will do a targeted regression.

No doubt there were one or more meetings to discuss this, when Marcus had already told them how unfeasible it was a couple of days earlier. It’s just that people with the authority to make the decisions, and the people that actually have the knowledge of how things work – are completely different people.

Gun ’em down

A tester had created loads of alerts and hadn’t disabled them. Jack sent a mass mail to rant about it, stating that any tests that can annoy others should always be cleaned up. He was doing some important testing and having alerts spam his screen was slowing him down and stressing him out.

Later, I sat next to Jack in a meeting and decided to wind him up about it.

timeinints: “Hey Jack, what are you gonna do about this testing situation? This happens a lot and we need to stop it.”

Jack: “What I’m gonna do, is march down to their office and gun them all down.”

The meeting host then points out that members the other office were on the conference call.

Well, that’s awkward. 😀

Care

After I write some code, I always test and inspect it thoroughly. I’ll write Unit Tests, running manual tests, constantly reading and re-reading the code. Any slight change I make, I then end up repeating the process. Even when I’m about to send it to review, I get paranoid that I’ve missed something, so end up looking at the files again to make sure.

It’s often rare that I get any (serious) feedback to change my code, and it’s rare that Testers will find anything wrong with it. But then sometimes I wonder if I’ve spent a little too long in the development stage.

However, Colin and Derek seem to take the opposite approach and end up coming out with something more quick and dirty.

Derek always seems to come up with a solution close to a hack which I’ll tear apart in the Code Review. After, it will end up being rejected by Testing and he will put in another bodge.

Colin spends time writing Unit Tests but often misses some scenarios. His methods often need refactoring down more, and methods/variables/classes may not have the best names. His solutions still come across as rushed, and he seems to cut more corners when the deadline approaches. When I point out his mistakes, he often says “the deadline is tomorrow night, so I just have to get it checked in”.

But surely it’s useless if it doesn’t work? In a similar fashion to “it’s better late than never”, you could say “it’s better that it is late and works, rather than getting it early and broken”.

He got some comments last week to refactor some of his methods. He quickly changes them and submits his new method for review. It was a one-line method, and somehow there were 3 mistakes in it. The thing is, he had Unit Tests covering every possible scenario of that method; he just didn’t run them. Unit Tests take a several seconds for a large batch of them to run; why would you cut corners so much that you don’t even run the unit tests? If you had full coverage, it will allow you to cut manual testing, but to cut testing completely? Madness.

Anyway, his code was something like this:

public string DisplayInfo(bool isScotland)
{
 return DisplayInfo(Configuration.Scotland==Configuration.Scotland); 
}

The 3 things that are wrong:

  1. he is passing in a parameter “isScotland” then not using it
  2. where he should be using “isScotland”, he is calculating it…but wrongly. He is comparing a value to itself; so it always evaluates to “True”
  3. The method just calls itself, which calls itself, which calls itself…until it crashes with a StackOverflowException because it’s an infinite loop.

Absolute Junior-level coding.