I recall playing You Don't Know Jack when they were an online venture, and they had different questions each week. The week of April Fool's they had questions that were practically unanswerable. Things such as the game would play a tone and then ask you which note it was (A sharp, C, Dflat, that kind of thing), or asked you to name an obscure political figure from way back when based on too little information. At the end, the game awarded you the full allotment of points you would have gotten if you answered all the questions correctly.
For the most part, the parent has the right of it. Specifications should drive what is tested. If the documents don't say the software should do "foo" then don't bother testing whether or not it does "foo", even if everyone is saying that it can, that it does and that it will do "foo".
But, the parent poster is a bit pie-in-the-sky for his last paragraph:
If there are no documented requirements, then you should ask yourself why you are working there. This situation usually leads to many arguments about what the code/product is really suppose to do, and you'll just become frustrated while you waste lots of time. It's not worth it.
Having no spec for code to be written is sadly becoming the norm these days. It would be nice to find and only work for companies that write specs for their projects, but if we all waited for that, there'd be a lot more unemployed coders/testers.
If you're stuck in the case where there aren't specifications, you'll have to take things into your own hands. You can do one of several things, each of which are likely to only work partially, so you'll probably have to organize them all.
Among those things are:
Ask the developers, or better yet the marketeers, to document what the software should do. You can even suggest that they don't have to do it all before you'll start writing tests from it.
Break down the software into functional units, and start writing the tests for those units. It'll help if you can get the developers/marketeers to review the tests, to be sure you're covering everything that the software does.
Just start hammering at the software.
Whatever you do, write down what you do. While the main function of testing is, indeed, to test the software, the best way to insure that is to make sure that every time you test you test the same things in the same way. If you write down what you do, then you can do it again the next build. Repeatability is the key, along with showing people what you're doing.
How can someone expect PRIVACY when they are walking down a PUBLIC street? By definition, privacy doesn't exist. How can you expect to have privacy when you are out there for all the world to see?
Then you claim:
I don't believe the government should tap my phone. I don't believe they should track my purchases. I don't believe they should outlaw software that allows me to encrypt my e-mail.
Unfortunately, one of those things is not like the others. Those purchases you make, if they are made in public spaces, are then public actions you claim are no more of an invasion of privacy than someone walking in a store and watching you. Either you'll have to start making all your purchases over the net, to ensure your privacy, or deal with the fact that people will watch what you consider 'private' actions.
I would like to point out the fact that I'm all for the "privacy of public spaces", and dislike the trends we're seeing. I'm just pointing out some issues I see with your logic.
But, could a local version help with RSI? I remember obnoxious programs which popped up every hour reminding you to take a break... how about something which popped up every 1000 key strokes (or whatever) reminding you to give you wrists a rest.
If you're looking for software that monitors keystrokes (and mouse movements, too) for RSI prevention, I'd recommend checking out RSIGuard.
You set preferences in the software to let it know how much typing it takes before you start feeling pain, as well as for mouse movements. From then on, it keeps track how much of those you do. After you pass a certain threshold, it will prompt you to take a break. A little display on the control panel even shows you how soon it thinks it the next break will be, both explicitly (34 mins to next break) and through a progress bar.
Um, no, that's not the way to go. From this page (sixth bullet down) on the BodyFueling site come three facts about excessive protein consumption:
Too little carbohydrate to run the body results in conversion of protein to carbohydrate to meet fuel needs.
Excess (unused) protein is converted to fat.
Converting protein either to fat or glucose is hard work, toxic--and unnecessary.
> I haven't read anything regarding renal stress associated with a high protein diet.
Elsewhere on the site, Robyn Landis points out "Eating excess protein also places a burden on the kidneys and can cause calcium and other important nutrients to be leached from the body--raising the risk of osteoporosis."
Her recommendation (which, by the way, combined with a workout regimen lost me 10 pounds in 2 months) is for 60% carbs, 20% protein and 20% fat. She also points out that you should not think of what you're doing as restricting what you eat, because that will make you resent what you're trying to do. Don't always force yourself away from the things you like. Have them, but only occasionally, and think of them as a treat.
All around, Robyn's book is pretty darn good. She manages to explain, in not-so-technical detail, just how the body works when fueling itself, along with a great bit of thought about why "diets" have problems working.
Slashdot Mirror
I recall playing You Don't Know Jack when they were an online venture, and they had different questions each week. The week of April Fool's they had questions that were practically unanswerable. Things such as the game would play a tone and then ask you which note it was (A sharp, C, Dflat, that kind of thing), or asked you to name an obscure political figure from way back when based on too little information. At the end, the game awarded you the full allotment of points you would have gotten if you answered all the questions correctly.
- Ask the developers, or better yet the marketeers, to document what the software should do. You can even suggest that they don't have to do it all before you'll start writing tests from it.
- Break down the software into functional units, and start writing the tests for those units. It'll help if you can get the developers/marketeers to review the tests, to be sure you're covering everything that the software does.
- Just start hammering at the software.
Whatever you do, write down what you do. While the main function of testing is, indeed, to test the software, the best way to insure that is to make sure that every time you test you test the same things in the same way. If you write down what you do, then you can do it again the next build. Repeatability is the key, along with showing people what you're doing.I would like to point out the fact that I'm all for the "privacy of public spaces", and dislike the trends we're seeing. I'm just pointing out some issues I see with your logic.
Um, no, that's not the way to go. From this page (sixth bullet down) on the BodyFueling site come three facts about excessive protein consumption:
- Too little carbohydrate to run the body results in conversion of protein to carbohydrate to meet fuel needs.
- Excess (unused) protein is converted to fat.
- Converting protein either to fat or glucose is hard work, toxic--and unnecessary.
> I haven't read anything regarding renal stress associated with a high protein diet.Elsewhere on the site, Robyn Landis points out "Eating excess protein also places a burden on the kidneys and can cause calcium and other important nutrients to be leached from the body--raising the risk of osteoporosis."
Her recommendation (which, by the way, combined with a workout regimen lost me 10 pounds in 2 months) is for 60% carbs, 20% protein and 20% fat. She also points out that you should not think of what you're doing as restricting what you eat, because that will make you resent what you're trying to do. Don't always force yourself away from the things you like. Have them, but only occasionally, and think of them as a treat.
All around, Robyn's book is pretty darn good. She manages to explain, in not-so-technical detail, just how the body works when fueling itself, along with a great bit of thought about why "diets" have problems working.
rthought .sig. Whoopee.
This is my