- This topic has 34 replies, 25 voices, and was last updated 7 years, 5 months ago by
.
-
Posts
-
I have come across a number of blog posts on some of the things you should never say to a software tester. Some of the ones I have read are:
“Can you hurry up and finish testing soon? We’re under a very tight deadline.”
“You must be bored out of your mind.”
“I didn’t have time to read your bug report. Give me the 5-second version.”
“Couldn’t a machine do this much easier?”
Have you had any suggestions that you would hate to hear? Have you been told any of the above?”
“You won’t break it” 🙂
or “I cannot break it”.
I was on a team developing application for Windows 8 (before its release). Team lead said “I cannot get a crash of our app for a hour whatever I do”. I switched my watch to stopwatch mode and started time count. I crashed app in 4 min 12 sec . Then second developer came and said “What about to do that at my machine?”. I took my watch to his machine and restarted time count. Second time I crashed the app in 3 min 24 sec. And then they wrote to general chat “Roma came and broke everything”“How it could be worse?”
My job is to look for worst case scenarios, so I should always be able to find how something could be even worse.“The real use will never do…”
I had read excellent article about that a few years ago, but unfortunately I forgot where I put it… 🙁 In fact problems which developers overlook may happen to real users.Update. I found it, the article I talked about!
Blog: Why Would a User Do THAT?“But it works on my machine” (esp because I work in mobile, and usually the devs use simulators, or a completely different device) — headdesk!
I find there’s a big difference between how each dev responds to bugs. Some love them. They get excited. Things you should say to a tester: “Good catch!”
Others will argue with me for as long as it would have taken them to fix it.
Guess which of those two produces the most bugs?
Most have figured out that I don’t back down but I do often get overruled by time/budget people.
One of the most annoying I hear regularly:
“Oh, that’s not a problem. Let’s leave it.”
(even if the whole system crashes…)@canuckjacq It sounds like you have to fight to get some bugs recognised as bugs. That’s never fun!
@andersr that’s a good one. It sounds like you have heard that a few times?Not sure if you know but I’ve recently collected some funny quotes between testers and developers. See if you like it.
I have heard many similar quotes while I’m testing. However,, not all of them are funny. Sometimes, they have the point when saying that.
Ex: ““Can you hurry up and finish testing soon? We’re under a very tight deadline.”
> It could be that this boss knows nothing about testing when he said this, but it could also means that deadline to release is more important than what you’re planning to test.@canuckjacq It sounds like you have to fight to get some bugs recognised as bugs. That’s never fun!
But you feel so good in the end when you have right 🙂
@ronan yes, it does happen 😀
Often when the person who is asking don’t have any other information or scope at all about the software uppgrade, I always reply with ‘It takes about the same time as it takes to drive a car’.
I may be the odd one out there but I don’t mind hearing any of those comments. At all. It’s just a reminder that there’s some work to do, other people to convince or educate who haven’t understood how testing fits into the SDLC. The questions or comments from these people are not the problem. It’s what we reply.
If someone says “It works on my machine” I ask if we can ship his machine then. If not, better fix that bug. If someone didn’t read the bug report there may be a valid reason. Depending on the situation I’ll sit down with them and walk through it, who knows, maybe even fix it right there and then.
Our goal is to get working software out of the door. If I need to put my ego in the closet for a moment and get the problem resolved I can do that. That’s not always the solution of course, figuring out when to push and when to offer help is a form of art.Thomas is exactly right. If these statements make you, the tester, angry, then it’s yourself you’re angry with—for not doing your full job. Each of these statements tells you something about the person saying them. It’s exaclly the same as output you get from a test run. You don’t get angry with the computer or the software because it has a shortcoming. You analyze the information in the output and use it (or give it to someone who can) to fix the problem.
So, when a p4rson talking to says something that shows they have a shortcoming where testing is concerned, it’s your job to analyze where that’s coming from and do something about fixing it. Ultimately, you’re not just testing software, you’re testing the people who produce and/or use that software.
Don’t try to fix other people. Let them say what they say. There’s nothing about them to be angry about, so if your response is anger, test yourself. Ask, “Why am I angry with myself?” You can’t fix them, but maybe you can fix yourself. At least that way there’s a finite chance of improving the situation.
– Jerry Weinberg https://leanpub.com/perfectsoftware.
1. ‘Just press ‘Done’. Heard that many times.
2. ‘We just change one code line. Nothing should be broken.’ Heh…but we, testers, never believe in that 😉You’re right on, Daria, with ‘We just change one code line. Nothing should be broken.’
Even worse, though, is when they say
‘We just changed one code line. Nothing could be broken.’
It’s that smug certainty that always points to a person who is pitifuly wrong.
I agree with Thomas, kinda. If you have worked with the team for a long time and you still get responses like above, it´s hard to keep your cool.
One of my favorites: “Oh, it just took me 10 minutes. Should be quick to verify as well!”When I’ve found a genuine defect prior to releasing into live to millions of users…
Can you not smile so much please?
We’ve had some good suggestions from Twitter too!
@esconfs "We didn’t change anything. Nothing should be broken."
— Sami Söderblom (@pr0mille) January 15, 2016@esconfs “we did a bit of refactoring"
— Richard Bradshaw (@FriendlyTester) January 15, 2016@esconfs "Would it delay testing if we added…"
— Fifty Grades of Shey (@SheyMouse) January 15, 2016
`I agree with Thomas.
You should be able to say anything (professional) to a tester. And a tester should be able to handle it.
Questions about how long it takes to test should at least lead to a guestimate.
Remarks concerning the amount of code changed should be met with the question how often that code is used by other code.
It is about how you handle the questions / remarks. You are a professional, handle it.
Just like a developer has to handle remarks how he created a fatal flaw in the software.My updated take @esconfs is that if you are still concentrating on testing then you are doing development all wrong. Test is dead.
— James Whittaker (@docjamesw) January 15, 2016
Is testing dead?
Hardly news since Whittaker has been saying this for years.
And the short answer is: Testing as activity is not dead.
Testing like we used to in the 20th century should be dead, but is not.
In an Agile team there are more/better unit tests and with prototyping and early involvement of users functional testing becomes less of an activity performed by testers. Arguably tester as seperate role could be dying. But that is not my perception or experience.
Testers now are much more technical savvy. They have to be.
Since we mostly work in Agile teams the testing role has changed.
So let us focus on the team. An Agile team is not a team of some generic designers/developers/testers blended into one entity. It is a team of specialist.
We have UI-specialists, performance specialists, data(base) specialists and, yes, Testing specialists.
As part of the development team our activities have changed and include coaching developers, risk analysis, end-to-end testing activities and more often than not involves specializing in one of the areas like test automation, security or performance.So a seperate test organization that receives software and performs tests on them?
Yes, that testing is (or should be) dead. It is outdated and does not deliver the quallity we demand.
Testing as specialist activity in a team? Not dead and probably will be around for a while.So where I disagree with Whittaker is that he assumes that tester as role is dead and that testing activities will magically be done by others like developers and users – who in reality will be unable to see beyond their own horizon.
Testing activities are here to stay – and so are the professionals who are best suited to perform them.@kasper wrote: “So a seperate test organization that receives software and performs tests on them?
Yes, that testing is (or should be) dead. It is outdated and does not deliver the quallity we demand.”1) In some cases specialist organizations are useful, e.g. with security testing. Not all orgs have the needed skills to do all the work they wish to be done.
2) For example for Apple this is important as they test apps uploaded to AppStore. Maybe this is outside the scope of your point, though.
3) Who are the “we” who demand quality?The “test is dead”, as far as I remember, comes from Nietzsche’s famous “God is dead” comment. It’s analogous with Jurgen Appelo’s Management 1.0 -> 3.0 transformation. BTW, Scott Barber wrote his list of 10 things that should die. It’s an interesting read.
For the actual topic of the discussion:
– QA this before we deploy to production
– Can we release the product
– Why didn’t you find this bug (can actually start a good conversation, but not cool when used as an accusation)
– Pretty much any absolute, like “never say to a tester” 😉 😉The one that always gets me is “You’re finding too many bugs”. So tempting to reply “No, you’ve created too many bugs” but us testers wouldn’t say that. Also, “It’s ok, users wouldn’t do that” – yep, first helpline call after release will prove that one wrong.
@jarilaakso below a quick answer to your points :
1) In some cases specialist organizations are useful, e.g. with security testing. Not all orgs have the needed skills to do all the work they wish to be done.
As a security professional I strongly disagree. Organzations should test for security from the moment they start designing. We have a lot of tools available for programmers and testers to check for security issues – just take a look at several OWASP documents.
After that you can still use external pentesters – but now they should find a lot less issues compared with trying to build in security after the functional coding is done. Also it is very complicated and (therefore) costly to fix security issues afterwards.2) For example for Apple this is important as they test apps uploaded to AppStore. Maybe this is outside the scope of your point, though.
This is indeed outside my scope although not completely. Apple needs to certify the applications in the AppStore and so they use their own organization to organize this. Still the apps in the AppStore should still be build and tested as described.
3) Who are the “we” who demand quality?
The “we” who demand quality are (at least in my case) the clients and regulators. Wether the clients are organizations, private users or sys admins does not really matter. The regulators are becoming more important all the time – and the costs for not complying are getting higher with each passing year.
Nice article. One of my favorites at the moment is……
“But it works on my machine!”
Very true, though my Personal favourite is:
“It works in the Dev Environment” or in the context that the AUT or SUT returns an error that stops the User working and the Defect Manager/PM/Lead Developer asks “Are you sure that the defect/bug is a Severity 2?”
And then they want you to come on call and replicate the whole process in their env. only to discover that both the env. behave in a different manner.
@jarilaakso below a quick answer to your points :
1) In some cases specialist organizations are useful, e.g. with security testing. Not all orgs have the needed skills to do all the work they wish to be done.
As a security professional I strongly disagree. Organzations should test for security from the moment they start designing. We have a lot of tools available for programmers and testers to check for security issues – just take a look at several OWASP documents.
After that you can still use external pentesters – but now they should find a lot less issues compared with trying to build in security after the functional coding is done. Also it is very complicated and (therefore) costly to fix security issues afterwards.Did you @kasper notice I wrote “needed skills” not “need for skills”? I am not sure what your comment disagrees with what I wrote.
- You must be logged in to reply to this topic.