I am working on a release at work. Initially we were supposed to replicate some bunch of database tables that the customer had in an old system. We did a quick dive into what was involved and came up with a rough level of effort. That translated into a schedule. The customer said the schedule as too long. Okay. Then if the schedule was fixed, we can up with a subset of the task we could finish on time.
Right no we are getting towards the end of the cycle for this release. Internal testers are trying to verify the work we did. One tester is sort of a programmer. She does automated testing with some Java programs she writes. Recently she sent out an email asking what she should test. LOL wut? I responded and directed her towards the requirements. Seems simple enough.
Later the test called me up. She said she wanted to send me a document. And she wanted me to mark it up and tell her what to test. Nope. First of all that's not my job. And second of all, she should not just test what I tell her to do. She should test what is required of us for this release. I had to say that a couple times. Use the requirements document. It is there for a reason.
I ended the call with the tester by telling her if she does not have the requirements document, call up our requirements analyst. She does not bite. Very simple. I worry that our testers do not know what to test. I don't want to be part of the problem by leading them astray. For developers who encounter a software problem, I say use the source. For everyone else, use the requirements.
Free Laundry
-
Apparently a lot of apartment buildings have coin operated laundry machines
in the basement. And guess what? You can order a key to unlock the payment
me...