I'm reading at article I saw posted:
http://gigaom.com/collaboration/5-ways-to-keep-your-rockstar-employees-happy/
And they wrote:
"Yet earlier this year, when Google interviewed its employees about what they valued most at work, none of these extravagant benefits made the top of the list. Neither did salary. Instead, employees cited access to “even-keeled bosses who made time for one-on-one meetings, who helped people puzzle through problems by asking questions, not dictating answers, and who took an interest in employees’ lives and careers.”
My question is, How do we convince the people that have held one or two jobs since graduating that they don't need more money? They are the ones that have had a first success, and are now far too expensive relative to their experience to hire. Do we hire them at the high salary, with silly benefits and just take that as the cost to hire, Knowing that that the benefits won't keep people engaged, it will just get their attention in the first place?
Monday, October 17, 2011
Friday, October 7, 2011
Pitfalls of exploratory testing
Exploratory testing is hard... if the product is difficult to use
1.
A product or feature with many days worth of nitpicky bugs could be "at risk" because a tester might be distracted by all the easy bugs and not spot a workflow (usecase) that is important.
2.
Features that are hard to use or configure might get missed. Consider a product with 10 major features, and 9 of them take 1 day to configure and get real data back from. The 10th requires 10 days to configure (it requires the sum of all other features to work) plus another day to collect data. In this case the testing is probably going to be interrupted (a customer escalation, a project date boundary, etc.), making it easy to forget to come back to feature #10.
Here are some ideas to mitigate these risks, do you have others?
-Use written testcases for these features. (Might be hard to know that you will hit problem 1 ahead of time)
-Do use case based testing, and track your results by use case instead of by program feature. (I want to try this idea on my current project, but have not yet)
-Put the best most "bloodhound" minded tester on that one problem area, and assume that they are up to the challenge.
1.
A product or feature with many days worth of nitpicky bugs could be "at risk" because a tester might be distracted by all the easy bugs and not spot a workflow (usecase) that is important.
2.
Features that are hard to use or configure might get missed. Consider a product with 10 major features, and 9 of them take 1 day to configure and get real data back from. The 10th requires 10 days to configure (it requires the sum of all other features to work) plus another day to collect data. In this case the testing is probably going to be interrupted (a customer escalation, a project date boundary, etc.), making it easy to forget to come back to feature #10.
Here are some ideas to mitigate these risks, do you have others?
-Use written testcases for these features. (Might be hard to know that you will hit problem 1 ahead of time)
-Do use case based testing, and track your results by use case instead of by program feature. (I want to try this idea on my current project, but have not yet)
-Put the best most "bloodhound" minded tester on that one problem area, and assume that they are up to the challenge.
Subscribe to:
Posts (Atom)