Next privilege 500 Rep.
Access review queues
Next badge 9/10
~19k people reached
- 0 posts edited
- 1 helpful flag
- 12 votes cast
Should you ever release something that you yourself could hack?
As someone relatively new to QA, I came into the work expecting "security flaw" bugs to be met with extreme gravity. But I've found that the label "security" doesn't always constitute a need for a zero-tolerance response. Some companies are perfectly happy to take security risks if the vulnerability doesn't appear to endanger the brand reputation, or offers hackers little to gain, and future releases are likely to include a fix (or feature change) anyway.
At which point do you “know” a technology enough to list it on a resume
An example of what I'm talking about in this answer: (Yes, I realize this is going to sound like I'm waving my own flag, and I apologize for that :$) ...I just converted a whole suite of IronPython tests I wrote 2 months ago, into C#. It was the first time I'd ever really worked with C#, but with a little kick-start from one of the dev's (about a 1 hour tutorial), I was able to take 3 weeks worth of Python work, and turn it over in C# in about three days. Now, to go back through the new code and look for improvement opportunities!!
Which Continuous Integration framework do you use and why?
Hudson is really great. Though, I do wish it was better at isolation. If you have a good number of different teams all working on loosely related projects, the potential for stepping on each other's toes is kind of high.