• (cs)

    Status should be "SNR: Should Not Reproduce"

  • jay (unregistered)

    If doing task X is not someone's primary job but an extra duty assigned now and then, it will almost always be done poorly and often not done at all.

    This is true even when it is for the own benefit. I have very, very often seen situations where, for example, the sales people were asked to test the new version of the sales reporting program before it went into production. One might naively think that they would see this as a very good thing to do, to make sure that the program works when they will actually have to use it, maybe even have an opportunity to suggest changes. But the amount of testing done in such situations ranges from little to none.

  • jay (unregistered)

    Many testers seem to think that the purpose of testing is to prove that the program has no bugs. The real purpose of testing is to find the bugs that are surely there.

    I've worked with testers who dismiss any bugs found with a "Oh, I must have done something wrong."

    I've also worked with testers who go into a total panic when they find a bug. They start crying that the program doesn't work, the project is doomed, we're all going to lose our jobs, etc. Almost literally. I got an email once from a tester who was literally worried that the project was doomed and anxiously asked what we should do because he found a couple of minor bugs.

    The best tester I ever worked with: He set a goal to find 100 bugs in every new release. Sometimes he had to stretch it, like calling a mis-spelled word on the screen a bug. But he almost always made it.

    I once visited a company that gave prizes to the tester who found the most bugs. Things like free pizzas and t-shirts, nothing super expensive. But it encouraged the right attitude: Your job is to find the bugs that are surely there.

  • monkeyPushButton (unregistered) in reply to jay

    We have no testers here but ourselves and any users we can convince to try it out. Had one co-worker who had a user testing it. They never reported any bugs. Project went live. Bug reports start flowing in. My co-worker talks to the test user to see if she ever came across that particular bug. Test user said she found it but didn't want to hurt the developer's feelings about there being a problem in the program.

  • trtrwtf (unregistered) in reply to jay
    jay:
    Sometimes he had to stretch it, like calling a mis-spelled word on the screen a bug. But he almost always made it.

    That's a bug: it's a thing that needs to be fixed. You don't want your testers trying to decide whether this is a bug or not. If they think it's wrong, they should report it, however small it is. It's a real drag when you go live with it, and you find it later, and the testers say "Oh, I didn't report that, because I wasn't sure it was a bug".

  • Ex-QA (unregistered) in reply to Another tester
    Another tester:
    In my experience, they are very few and very far between
    Not surprising. If you're intelligent, capable and have the right mindset to be a good tester ("here's a system - what are the flaws and loopholes") there are a hell of a lot better ways to earn a living. Tax law, for a start.

    Very true. I was a pretty good tester for many years, and when I couldn't find a job after getting laid off during the recession (everyone seemed to cut QA first and the only companies hiring were just looking for entry-level positions), I knew just enough SQL to land a jr. db position. I've been a DBA now for over 4 years and will most likely never go back to a testing position.

  • (cs)

    That's where a lot of QA departments fail: they're seen as entry-level. Anyone good enough to rock QA would be even better as a developer.

  • C-Derb (unregistered) in reply to trtrwtf
    trtrwtf:
    jay:
    Sometimes he had to stretch it, like calling a mis-spelled word on the screen a bug. But he almost always made it.

    That's a bug: it's a thing that needs to be fixed. You don't want your testers trying to decide whether this is a bug or not. If they think it's wrong, they should report it, however small it is. It's a real drag when you go live with it, and you find it later, and the testers say "Oh, I didn't report that, because I wasn't sure it was a bug".

    I had a tester (who was a dead ringer for Dilbert's coworker Wally, in terms of appearance, coffee mug and work ethic) one time report a bug someone else found. I made the fix and let him know it was ready to be re-tested. He reported back the next day that it passed and gave the code release his blessing. I checked the testing database for any new records generated by this piece of code and found absolutely nothing to support the idea that anyone had used it between my check-in and his assertion that all was well. He didn't have direct database access (thus, no possibility of deleting records or doing something else to cover tracks), so I knew for a fact that he hadn't actually tested anything and I called him on it in a meeting with the Development Manager. He eventually admitted that he hadn't actually tested things, but somehow kept his job.

    I took another job shortly thereafter.

  • lolatu (unregistered)

    In our bug tracker we can mark bugs as 'Rejected'. People whose bugs get rejected tend to get a bit upset. So now we yell it out loud as well.

  • trtrwtf (unregistered) in reply to chubertdev
    chubertdev:
    That's where a lot of QA departments fail: they're seen as entry-level. Anyone good enough to rock QA would be even better as a developer.

    Same problem applies to documentation as well: everyone agrees that they're both really important jobs. They should be done, and done right. Doing them right pretty much requires someone who's got enough skill to make a meaningful contribution to the code. Someone who can make a meaningful contribution to the code, should be doing that, and they would rather be doing that, and they want the pay that comes with doing that. So testing and docs never get done, because they're very important and they should be done right.

  • (cs) in reply to jay
    jay:
    Many testers seem to think that the purpose of testing is to prove that the program has no bugs. The real purpose of testing is to find the bugs that are surely there.

    I've worked with testers who dismiss any bugs found with a "Oh, I must have done something wrong."

    I've also worked with testers who go into a total panic when they find a bug. They start crying that the program doesn't work, the project is doomed, we're all going to lose our jobs, etc. Almost literally. I got an email once from a tester who was literally worried that the project was doomed and anxiously asked what we should do because he found a couple of minor bugs.

    The best tester I ever worked with: He set a goal to find 100 bugs in every new release. Sometimes he had to stretch it, like calling a mis-spelled word on the screen a bug. But he almost always made it.

    I once visited a company that gave prizes to the tester who found the most bugs. Things like free pizzas and t-shirts, nothing super expensive. But it encouraged the right attitude: Your job is to find the bugs that are surely there.

    +1

  • gnasher729 (unregistered) in reply to TheSHEEEP
    TheSHEEEP:
    Also, while that is indeed a tester WTF, it is also an OS WTF.

    No OS I've worked with keeps a history of the clipboard (on Windows I'm 100% sure, on Linux & OSX almost sure). Why? What's so hard about it? I always have to install additional tools for that :/

    Just tried in MacOS X. Doesn't work. I started typing this reply, then restarted the Mac, and the website with the reply that I started come back up, but the clipboard was gone.

  • gnasher729 (unregistered) in reply to jay
    jay:
    Many testers seem to think that the purpose of testing is to prove that the program has no bugs. The real purpose of testing is to find the bugs that are surely there.
    Neither. The purpose of testing is to help developers reduce the number of bugs, and to help management to decide whether a product can be shipped or not.

    Difference between "finding bugs" and "helping developers reduce the number of bugs" is the effort put into writing bug reports that enable a developer to find and fix the problem.

  • Bananas (unregistered)

    I can't tell you how many times I've copied on one computer, turned to another computer and hit paste expecting that to work. But it should work that way, right? Somebody needs to design a clipboard that stores the data in me.

  • (cs) in reply to faoileag
    faoileag:
    BDX:
    Linux user here... How many times I cursed a windows application for the paste command being greyed out, before realizing I just forgot to copy.
    How many times I cursed at a windows application, when, after having some text selected with the mouse, it did not appear in a textbox after pressing the middle key of the mouse!
    How many times I cursed at a Linux application, when, after having some text selected with the mouse, it unexpectedly appeared in a textbox after accidentally brushing the touchpad with my wrist!

    Seriously though, this is a tremendously annVEGETABLE PORNoying problem, and there is absolutely no way to turn off this "feature" that is the bane of my entire exisHOW TO BOLD TEXT IN BBCODEtence.

  • foo (unregistered) in reply to Bananas
    Bananas:
    I can't tell you how many times I've copied on one computer, turned to another computer and hit paste expecting that to work. But it should work that way, right? Somebody needs to design a clipboard that stores the data in me.
    Apple's iWatch can do this.

    (Well, I don't really know, but I hear it can do anything.)

  • Norman Diamond (unregistered) in reply to QJo
    QJo:
    C-Derb:
    The idea of testers getting to know the underlying technology is a pipe dream. For example, the testers I work with now get so hung up on issues that "look wonky" because they are testing with our "test" database that has a few records that are complete crap. But that doesn't mean that I get to avoid being interrupted 4 times a day to re-explain where the data is coming from and why it looks that way and how you could verify this for your retarded self!

    The very thought, "Gee, this page looks correct for all ten of these scenarios except the last one...I bet it is a data issue, I'm going to go verify" just never seems to enter their heads. So much easier to just log a bug.

    After it has happened the second time, you take steps to amend the test database so that it no longer contains wonky records.
    No, your testers need debugging and you need to keep the wonky records.

    GIGO = garbage in, garbage out. You need to make sure your program does this.

    GIC = garbage in, crash. If you don't test wonky records, you get this ... if you're lucky.

    VIVOVOVOVOVO = virus in, virus out... if you don't test wonky records.

  • Tae Wong (unregistered)

    Excel clears the undo stack on Windows shutdown. There is no registry key to change this behavior.

  • Anonymous (unregistered)

    We have testers at the absolute far ends of the scale when it comes to testing-competence. Unfortunately, in our team we're stuck with the low end guy. But luckily he knows how low his competence level is.

    The problem comes from people who think they know what they're doing, when they don't.

  • Another tester (unregistered) in reply to chubertdev

    Yes, and it's something that's causing a huge skill shortage at the moment - the lack of technical testers is ridiculous, and the demand increases with every company that switches to Agile. Before I started contracting in January I was getting 6-8 approaches a week just on the basis of having C#, Java and Ruby skills. I interviewed at a few of the places, turned down the offers but found out that in some cases they'd been interviewing for over a year just to find testers who could code. As it is, I'm having to turn down enough work to start an actual consultancy (rather than the tax dodge ltd company I have now).

  • (cs) in reply to SamC
    SamC:
    How many times I cursed at a Linux application, when, after having some text selected with the mouse, it unexpectedly appeared in a textbox after accidentally brushing the touchpad with my wrist!
    How many times I cursed at a Linux application, when, after trying to focus a shell window, I accidentally dragged my mouse a tiny bit thus causing said shell window to automatically replace my clipboard contents with some whitespace or random contents of the shell window.

    I mean, honestly, what kind of demented monkey thought that copying from shell is so frequently and excessively used that a simple keyboard shortcut was insufficient?

  • Herr Otto Flick (unregistered) in reply to Steve The Cynic
    Steve The Cynic:
    faoileag:
    BDX:
    Linux user here... How many times I cursed a windows application for the paste command being greyed out, before realizing I just forgot to copy.
    How many times I cursed at a windows application, when, after having some text selected with the mouse, it did not appear in a textbox after pressing the middle key of the mouse!
    It's not inherently desirable that selecting text will automatically and silently destroy the contents of the clipboard. Maybe I just wanted it selected so I could delete it, or turn it bold, or some such, not because I wanted it in the clipboard (and also I wanted to keep around what was already in the clipboard).

    And there are other issues surrounding that, like the twisty-passaged management of clipboards, X selections, and kill rings in GNU Emacs. Twisty-passaged bollocks that manage to change in odd ways between versions. (I still haven't got it behaving correctly since my last update about a month ago.)

    Well done, you've demonstrated you have no concept of the difference between the select buffer and the clipboard in X11. Stick to Windows, or if that is too tricky, try OS X - it's only got one button on the mouse, even my gran can handle it.

  • ZoomST (unregistered) in reply to jay
    jay:
    I once visited a company that gave prizes to the tester who found the most bugs. Things like free pizzas and t-shirts, nothing super expensive. But it encouraged the right attitude: Your job is to find the bugs that are surely there.
    Nice way to encourage false positives.
  • Enterpricey contractor (unregistered)

    When your testers are (physically) the same people as your technical designers / architects, there are few feelings that can top the status of "Works as Designed" ~ poorly...

    captcha - immitto -> trying to immitate immitating?

  • (cs) in reply to QJo
    QJo:
    BDX:
    Linux user here... How many times I cursed a windows application for the paste command being greyed out, before realizing I just forgot to copy.

    TRWTF is that Mark did not make any attempt to retry his copy/paste action before raising a ticket.

    Any fule kno you're got to reproduce your bug before reporting it. You never know, you may just have fumbled the buttons first time round.

    As a professional tester ("professional" only means i get paid to do it) I quickly learned that if I can't reproduce the bug, the developer will have my head on a plate. I not only reproduce it, I document every step so even the pointy-haired boss can reproduce it :-)

  • (cs) in reply to Another tester
    Another tester:
    Yes, and it's something that's causing a huge skill shortage at the moment - the lack of technical testers is ridiculous, and the demand increases with every company that switches to Agile.
    And yet, without recent coding experience my extensive testing background means squat to recruiters. All anyone wants today are SDETs, and the years of coding I did prior to my years of testing don't seem to count. Indeed, the combined total of my experience only shows my age, another reason to skip my resume.
  • Dave (unregistered) in reply to dkf
    dkf:
    apps having just their own internal notion of what is selected rather than a global one.

    This, now this, is TRWTF.

  • jay (unregistered) in reply to Bananas
    Bananas:
    I can't tell you how many times I've copied on one computer, turned to another computer and hit paste expecting that to work. But it should work that way, right? Somebody needs to design a clipboard that stores the data in me.

    Yeah! Like, I don't know how many times I've had this situation: I have two windows up. I do something on window A. Then I type or click something on window B. Then I look at window A and start typing, and for some reason the text appears on window B! What's wrong with this silly computer? Just because that's the last place I clicked doesn't mean that's where I want the stuff I type to go. It should go in the window that I'm looking at and thinking about.

  • jay (unregistered) in reply to ZoomST
    ZoomST:
    jay:
    I once visited a company that gave prizes to the tester who found the most bugs. Things like free pizzas and t-shirts, nothing super expensive. But it encouraged the right attitude: Your job is to find the bugs that are surely there.
    Nice way to encourage false positives.

    I'm sure that problem could be solved by simply saying that only bugs that are not rejected count. Sure, otherwise people could just make up bug reports. If it's a real problem, at some point you start giving minus points for bogus bug reports.

  • Remy Lebeau (unregistered) in reply to n_slash_a

    I would have closed it as "Closed - Test Case Error" instead.

  • Remy Lebeau (unregistered) in reply to n_slash_a
    n_slash_a:
    No, TRWTF is that he closed the ticket with the status "Closed - As Designed" when he really should have closed the ticket with "Closed - Out of Scope", as this would be an OS issue and not an application issue.

    I would have closed it as "Closed - Test Case Error" instead.

  • (cs)

    This is why all bug reports that make their way to the development staff need to have FULL and COMPLETE steps for reproduction. Having the developer try to figure out what the user was doing only wastes his time. If the bug isn't reproduced with the steps given, it should immediately be sent back stating "Unable to reproduce".

  • Bill C. (unregistered) in reply to GoatCheez
    GoatCheez:
    This is why all bug reports that make their way to the development staff need to have FULL and COMPLETE steps for reproduction. Having the developer try to figure out what the user was doing only wastes his time. If the bug isn't reproduced with the steps given, it should immediately be sent back stating "Unable to reproduce".
    Bug report optional. Development optional. Staff mandatory. User optional. Bug optional. Intern mandatory.
  • David (unregistered) in reply to GoatCheez
    GoatCheez:
    This is why all bug reports that make their way to the development staff need to have FULL and COMPLETE steps for reproduction. Having the developer try to figure out what the user was doing only wastes his time. If the bug isn't reproduced with the steps given, it should immediately be sent back stating "Unable to reproduce".

    Of course. If you're not running the developer's exact hardware, you don't deserve to have the code work right. If the developer is running a dual-monitor setup, or a Dvorak keyboard, or has 12 GB of RAM, or has /tmp on his main partition instead of RAM, or is running Ice Cream Sandwich on the test phone, everyone who wants to run the program should have to have the same environment.

  • Norman Diamond (unregistered) in reply to David
    David:
    If the developer is running a dual-monitor setup, or a Dvorak keyboard, or has 12 GB of RAM, or has /tmp on his main partition instead of RAM, or is running Ice Cream Sandwich on the test phone, everyone who wants to run the program should have to have the same environment.
    ?????!

    Oh sorry, wrong thread. There will be cake.

  • AN AMAZING CODER (unregistered)

    This tester could have saved lots of time and effort by either:

    a.) Calling the reporter on the phone b.) Walking over to their desk.

    Instead of bitching at my users for being terrible at writing bug reports, I have them show me the bug. It might seem counter productive, but I can assure you that for the worst offenders it's incredibly less waste of time than attempting to get them to be better at writing bug reports. I've found they either intentionally don't report things because they think it's not important (the fact that I'm on my Windows machine and not my Mac made no difference last time... so why would it this time?), or because they believe they'd be wasting your time or insulting you by doing so.

  • TortoiseWrath (unregistered) in reply to scotty
    scotty:
    faoileag:
    BDX:
    Linux user here... How many times I cursed a windows application for the paste command being greyed out, before realizing I just forgot to copy.
    How many times I cursed at a windows application, when, after having some text selected with the mouse, it did not appear in a textbox after pressing the middle key of the mouse!

    How many times have I cursed at a windows computer, when, after picking up the mouse as saying "Hello Computer" I get no response

    You have to say it in Japanese!

    (3rd Rock from the Sun reference, for those who haven't yet caught on.)

  • urza9814 (unregistered) in reply to C-Derb
    C-Derb:
    I would give up 10% of my salary to work with one of these so-called "Good Testers". In my experience, they are very few and very far between. Most testers are like Mark. People who don't think on a larger scale. People who simply log a bug without thinking, "Let's see if the Paste option behaves similarly in, oh I don't know, Microsoft Word if I copy some text and then reboot my machine.....Oh, yep, same behavior. Definitely not a bug."

    The idea of testers getting to know the underlying technology is a pipe dream. For example, the testers I work with now get so hung up on issues that "look wonky" because they are testing with our "test" database that has a few records that are complete crap. But that doesn't mean that I get to avoid being interrupted 4 times a day to re-explain where the data is coming from and why it looks that way and how you could verify this for your retarded self!

    Man, tell me where you work so I can avoid it! Our testers frequently write their own SQL queries to validate that the data in the DB is the same as the data in the application. Nobody does any code for them -- they write code to generate test data, to automate testing, to analyze the data, etc. At a minimum they know the basics of SQL, ksh, and Java. If you wrote the code they're testing, you can expect they'll come back a few times with 'Is there any way you can get us this extra data? Is there a way to test this additional case?' And they won't accept 'we don't have that data' -- they'll keep asking until you find a way to get it! And even when someone else has written all the test cases for them, they'll still try to find new ones to add! I had one recently where one of the more senior testers had written out all the test cases, then had to hand it off because it ended up entering testing right as he was taking a week off. The guy who ended up doing the testing doubled the number of test scenarios before he even started. And this was for a ~20-line SQL script designed to extract a report from a test server! It was a single SELECT statement, that was only to be run once, that wasn't even touching production! Good to know that's what's between you and "YOUR CODE BROKE IN PRODUCTION!" though :)

  • RockyMountainCoder (unregistered) in reply to faoileag
    faoileag:
    the company didn't feel that having dedicated testing resources delivered sufficient benefit for the cost
    That's what interns are for!
    Mark:
    After I shut down your application, I restarted the machine.
    A guy who does not even know that the contents of the clipboard gets lost once he shuts down/reboots his machine is doing front-line support?

    The WTF in the story is obviously Mark, but a company that doesn't see any value in a dedicated QA team and tasks people like Mark with front-line support is definitely a WTF in its own right.

    I hope I'll never have to deal with them/their software...

    You've obviously never had to hire for a support desk position.

    Anybody worth keeping can't be kept. Anybody who can be kept isn't worth keeping. Your best bet is to hire college students and hope you find one who doesn't have a drug problem. You can get about 18 months from them, if you're lucky, but you'll have to change their schedule every semester.

  • trololololol (unregistered) in reply to anonim
    anonim:
    The final insult is the smiley at the end.
    Right. As recounted here, this is clearly an instance of Mark trolling the fuck out of Eric. Sort of like those "lateral thinking" puzzles: 
    Summary: Elevator/stair usage inconsistent
Status: Open
Assigned to: Eric
Filed by: Mark
Filed: 2013-05-02 13:57:01
Description:

Occupant of room #1253 always takes elevator to lobby in morning; sometimes walks and sometimes takes elevator in evening. Explain please.

Changed by: Eric
Reassigned to: Mark
Comment: Is the elevator sometimes out of service and that's why he takes the stairs?

Changed by: Mark
Reassigned to: Eric
Comment: No, the elevator is never broken. Did I mention that whether he walks or takes the elevator is correlated with the weather outside?

Changed by: Eric
Reassigned to: Mark
Comment: Are there windows in the stairwell?

Changed by: Mark
Reassigned to: Eric
Comment: No.

Changed by: Eric
Reassigned to: Mark
Comment: Is there something special about the man's profession?

Changed by: Mark
Reassigned to: Eric
Comment: No. Did I mention he's a midget? :)

Comment by: Eric
Comment: wtf mark
  • testwithus (unregistered) in reply to n_slash_a

    SWIFT Interview questions on

    http://testwithus.blogspot.in/p/swift.htm

    For selenium solution visit http://testwithus.blogspot.in/p/blog-page.html

    QTP Interview Questions. http://testwithus.blogspot.in/p/qtp-questions.html

    www.searchyourpolicy.com
  • AC (unregistered) in reply to ZoomST
    ZoomST:
    TRWTF: <<... Slowly and deliberately Mark moved the mouse over to the Status combo box for the bug, opened up the options and selected "Closed - As Designed".>> So Mark was changing the status... meanwhile Eric was feeling pity for Mark. Sounds like psychic abilities for me.

    Maybe Eric had just reached an epiphany that he and Mark are actually one and the same, a la Tyler Durden.

    erat: Virtual plaything for the iCat.

  • ebohlman (unregistered) in reply to A tester

    In fact, it's worth reading Gerald Weinberg's (somewhat dated in terms of the examples, but timeless in terms of the principles) The Psychology of Computer Programming just for his observation that "debugging" really consists of at least three psychologically distinct tasks and that each optimally requires a different pattern of personality traits and cognitive skills (i.e. what makes someone good at one of them doesn't necessarily transfer to the others).

    FWIW, they were:

    1. Determining that something is wrong in the first place; the fact that Weinberg considered that part of debugging rather than testing reflects the age of his work (written in 1971, though there's a newer edition).

    2. Determining where the problem is in the code.

    3. Determining how to fix the problem without introducing more bugs. We've probably all met someone who's good at the first two skills and sucks at this one.

    Expanding on that analysis, it seems that Mark was well-suited for testing but ill-suited for customer support. A good tester needs a certain amount of naivete about how the stuff he's testing works internally (unless the users are expected to be familiar with the internal workings) because otherwise he'll have certain blind spots based on his expectations of how things should work (see Weinberg's discussion of "psychological set"; we've all stared at (buggy) code we've written and seen what we intended to write rather than what we actually wrote).

    On the other hand, a good support person needs to be familiar with all the quirks of the stuff he's supporting and has to know how at least the broad aspects of the internal implementation work in order to make a good guess at what's causing the user's problem, whether that guess results in advice to the user or filing a ticket with the developers.

    Captcha: sagaciter--someone whose writing contains frequent allusions to the adventures of fictional heroes from the past.

  • squelchbaker (unregistered) in reply to BDX
    BDX:
    How many times I cursed a windows application for the paste command being greyed out, before realizing I just forgot to copy.

    That's what the middle-click instacopy is for. It's probably the most useful thing ever. I use Linux at home, but I have to use Windows at work, and I always have to stop myself because I try to do it every time I have text selected.

  • (nodebb)

    this is very imposible

  • (nodebb)

    The development of empathy is, of course, crucial for any type of communication. There is currently no way without this. I can therefore speak for myself when I say that looking at and carefully reading essays on empathy at https://papersowl.com/examples/empathy/ is the finest course of action. For instance, I consider myself extremely fortunate to have discovered all of this data. At least I became aware of it. I hope I was able to be of assistance. Good fortune.

    Addendum 2022-10-21 21:17: The development of empathy is, of course, crucial for any type of communication. There is currently no way without this. I can therefore speak for myself when I say that looking at and carefully reading essays on empathy at go to website is the finest course of action. For instance, I consider myself extremely fortunate to have discovered all of this data. At least I became aware of it. I hope I was able to be of assistance. Good fortune.

  • kevin stelly (unregistered)
    Comment held for moderation.
  • Chemical Engineering Assignment Help (unregistered)

    After all assignments are given to the students for their welfare but if this is not taken seriously then it might harm the academics so it is always better to go for a .Chemical Engineering Assignment Help which is always a better option. https://greatassignmenthelper.com/chemical-engineering-assignment-help/

  • John Swan (unregistered)
    Comment held for moderation.
  • (nodebb)
    Comment held for moderation.

Leave a comment on “Testing Patience”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article