Hacker News new | past | comments | ask | show | jobs | submit login

Reproducability is great.

No, my concern is that if I submit a ticket that says "when I send 65 characters in the Username field I get random spew back, I think you need to be checking inputs better" and get a response of "show this to me with a PowerShell script" then I kick things upstairs with appropriate commentary.

And if the attitude you related in these comments is accurate, I suspect those engineers all have something else in common: working to bypass you as much as possible.




I think that

start my-fancy-app.exe; Sleep; [System.Windows.Forms.SendKeys]::Send("A"*65)

makes it way more reproducible and you even quickly get test from there (would do that in AutoHotkey tho for better effect, right tool for the job).

> And if the attitude you related in these comments is accurate, I suspect those engineers all have something else in common: working to bypass you as much as possible.

Actually, its quite the opposite. With that attitude tho, I suspect you get bypasses all the time.


And if something else has (or grabs) focus and the scripted input doesn't go where you're hoping it will, does the bug report get marked "can't reproduce" and closed?

I'll freely confess I'm not up on the current automated testing tools for Windows apps, but I'm hoping they're more sophisticated that "point and pray" keyboard spamming.

My concern with the approach you describe is that there are many categories of application problems that are not reasonably reproducible with a PowerShell script, some that are reproducible only with a sophisticated script, and some that are trivially reproduced.

For the trivial ones that are easily reproduced my feeling is that a quick description going to the developers will probably let them reproduce it more easily in a development environment with appropriate code stops that would be adversely affected by automated keyboard injection directly to Windows. For Windows app development if I put in a code stop to inspect state after each keypress, blowing 64 extra "A"s into my dev environment after the stop is unlikely to be helpful.

For problems that require more sophisticated scripting to reproduce, I'm unconvinced that I want to be requiring that all testers be able to write sophisticated test scripts. Maybe you have a ton of VC money and feel that burn rate isn't relevant, but that doesn't describe everyone. Sure, I want some good automated test scripts and the ability to say "When we run script XYZ with input set ABC it blows up" but scripting reproduction of every scenario? (expletive) no.

Basically you're putting up a sign that says "I don't care what problems you have found, if they can't be reproduced with an automated script I will reject them." That doesn't keep those problems from existing or being found, it just ensures that you don't try to fix them and eventually (if you're still around) it means that you don't hear about them either. That may never cause real problems, or someday you may get an email from Tavis Ormandy or someone you have even less desire to hear from.

Edit: it just occurred to me - basically this is a "captcha" system for bug reporting, but one with the potential for arbitrary puzzle difficulty potentially unrelated to problem severity or reproducability.


Didn't I tell AHK is the tool for that job ? It handles stuff like focus stealing, theming etc without any problems. Seriously, if there is no test, it might just be your high sugar levels. I don't know in what kind of stuff you are, but we develop software and services that entire country uses. If you do not make a test you can regress and it will probably happen in the worst possible time.

Also, I don't have testers, only developers. Testing is the part of the job which is mandatory. Along with some other stuff. :)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: