Beta testing is like test driving a new production automobile model. As a car driver, you know what a car is supposed to do. Designers and engineers know what they want the auto to do, new or differently, than before. As the test driver you want to check out those specific features to make sure they're working accordingly. Hopefully as the "tester" you've been given a list of what's been added/upgraded/changed. Software is the same way. It's a constantly evolving package. New features are added, old features are tweeked. But there's one big difference between automobiles and software. Most auto engineers (I might even be so bold as to say ALL) have driven cars. They know how cars should work for the consumer, they know what a car needs to accomplish, and what things are imperative. In software development this is not always the case. Often a programmer has never worked in the particular industry he's programming for. That's where the "interpreter" must come in. The person between the user and the programmer. The interpreter listens to the user, evaluates the need, tries to design a solution to the need and present it to the user. Sometimes the interpreter must approach the programmer. Programmers ... are certainly not a "one-size-fits-all" class of people. But I am willing to say, that almost universally they have definite "ideas of their own". Most HATE for you to approach them with a problem and then utter this fatal phrase, "And here's how you can fix it". My personal experience has led me to believe anytime I utter those words, I will never see a resolution to the problem, and most certainly NEVER the resolution I suggested. Apparently I have no idea how anything can be fixed. My sole role is to establish a need, prove to the programmer the validity of the need (thank God I took pre-law and debate classes), and accept the programming resolution. After the resolution has been released for Beta Testing, I become "Miss Cranky-Pants". In fact, I have been playing the role of "Miss Cranky-Pants" at work for the last two weeks. It's not a role I enjoy, and although I could win an award for it, the programming staff HATES me in this role, too. I've tried explaining to them that I would cheerfully try out for some other position, if they'd just work with me on developing a different script. Our current script goes like this: PG: (Programming God for the uninformed) Test the release items, make sure they're working. I want to publish before Friday. MCP: Okay! I'll get on it right way. *minutes pass* MCP: Uhh PG?, it says you fixed the blah blah blah and added a reporting item so I can make a computed item. PG: Yep, I did. MCP: Can you tell me the name of the new item, so I can test it? PG: I'm busy. Don't bother me now. MCP: Are you busy for a short time or a long time? PG: -CLICK- So I go to the next "fixed" item. This particular item has never previously been incorporated into the product. The fun part about beta testing? No road map. No mention in the beta release of "what" has been added to meet the need. It's this great game of hide and seek. They hide the solution and I get to seek it out. Moving right down the list of items, I hit the next stone wall. Luckily for me, I have the customers data, and I remember the specific problem. I spend about 1/2 hour getting the scenario set up. I test, the test fails. I fail the fix. A notification of the failure is automatically fired off to the Programming Gods. Within seconds my phone rings. PG: Why'd you fail this? MCP: It didn't work. PG: It does work! I tested it myself. MCP: Well, it's not working for me. Do you want to come here and take a look? PG: It works on my computer MCP: I'm happy for your computer. However it doesn't work on mine. And if doesn't work on mine, it's not going to work on the client's. PG: How'd you test it? MCP: I blah, blah, blah, and then I created blah, blah, blah - and it didn't do anything. PG: Well, that's not the way you're supposed to test it. I didn't design it to work that way. MCP: Since there's no documentation in the "What's new", perhaps you'd like to share your little secret with me? You know, so I can test it, and NOT fail the solution? PG: I'm busy, I'll be up there later. The most annoying of all are the solutions that don't meet the clients needs. The lack of "fit" between the need and resolution is so large - Grand Canyonish Large - it's almost funny. (afterwards) It's like this: MCP: The industry needs to present a hot meal to their customer. This is a new need. In the past they only had to present room temperature meals. PG: We can't do that, we can't make meals. MCP: We're ALREADY making meals, they just have to be HOT. PG: There's nothing in our program that will allow you to make a HOT meal. MCP: Yes there is! Look, over here we have segmented serving dishes, over here we have sauteed chicken breasts, and here - look nice cooked carrots. Last week you even added this new database segment of desserts. It's perfect. You just need to make it HOT. PG: It will take a long time to program. I can't do that now. MCP: The GOVERNMENT is going to require HOT meals in 2 months. We HAVE to have it. PG: *sigh* I'll see what I can do. *one month and 3 weeks and 4 days pass by* PG: Test the hot meal process. I'm ready to release. MCP: Okay. *several hours later* MCP: This isn't HOT, it's FROZEN. The industry requires HOT. PG: It is too hot. MCP: It isn't HOT. I've worked in this industry. In order for it to register "HOT" it has to be over 100 degrees. This is 32 degrees. That's FREEZING. PG: It's hotter than 0 degrees. MCP: Over zero ISN'T HOT. It's not even CLOSE to HOT. The government isn't going to accept this. Not ony that, do you know how many steps I had to go through to get the meal? No one has time to do all that. PG: Fine, we'll make the meal - the government can make it hot. MCP: No, the government CAN'T make it hot. WE have to make it HOT and EASY. PG: Well, I think this is the way it should work. MCP: Hello! Are you listening to me? "THE INDUSTRY" doesn't work this way. "THE GOVERNMENT" requirements have changed. Our clients must be compliant TOMORROW! Now, why can't we blah, blah, blah after the meal is put together? Won't that make it hot? PG: That's not the way I want it to work. MCP: *throwing up her hands and storming around the office* Okay, I KNOW there's some mystical programming Bible you studied for years and years when you were in the psych ward. I KNOW my solution isn't ELEGANT. I concede, it's not what YOU had in mind. However if I can make it work through the back door then YOU can make it work on the front end. NOW! PG: If you keep yelling at me, I'll never program it the way YOU want it. MCP: *with slightly higher pitched voice* It's not the way "I" want it. It's the way "it has to be", ok? It's the way the STUPID industry does business. It's the way the F'd up Government wrote their regulations. Can you just PLEASE, PLEASE, help me out here? So I can quit annoying you and go away? PG: You'll go away if I make it hot? MCP: Yes, Yes, I'll GO AWAY. Just make it HOT and EASY. *an hour passes* PG: If you come back to my office I can show you the Hot Meal. MCP: Really? So soon? I'll be right there. *walks into the exalted office of the programming god* MCP: Show me! I can hardly wait. PG: See, you load it here, you click here - and Voila - a HOT MEAL. MCP: That's PERFECT! See I knew you could do it! Great job! I can't wait to show the client. Now about that other thing ... PG: You said you'd go away if I made it hot. Now go away. MCP: But, but you never fixed the other problem. You were too busy to talk about it. PG: You said you'd GO AWAY ... now scram. Get out of here. You made a promise. I kept my end, now you keep yours. MCP: But, but ..... PG: *waving* Good-bye "Miss Cranky Pants". MCP: - Fine! I'm leaving. I'm going home to drink. But I'll be back tomorrow, and you'll HAVE to talk to me then. I only promised to go away for one day so there! PG: I don't remember that, that's not what you said! MCP: Yeah, well ... too bad! Currently the Programming Gods and Miss Cranky Pants are calling a truce - for Thanksgiving Day. She'll be returning to her job on Monday, and they'll be returning to ... sit in their offices and avoid her.