February 24, 2006 at 9:01 am
We are actually going to set up a complete test environment with real servers and real client pcs. It won't be large, in fact it will probably be one retired server and four or five pentium IIIs. At least it will be a separate sandbox type area before production. We had a mishap a couple months back that spawned the creation of this test environment. We used to be a test in production group as well.
February 24, 2006 at 9:21 am
Mr. Buchan has a very good point. Fully automated testing misses many flaws that are obvious to the user. I have been an advocate for some degree of ad hoc testing in addition to automated testing but that is more difficult to manage. If you start "clicking around and seeing if things work" it is harder to know when you are done?
February 24, 2006 at 9:30 am
When I joined the company things were in a bit of flux. Mostly test by production was done but there were a few cases where a test DB was used first. Now we have a full test environment including test users and a separate test server. Things still get broken, and pushed into production but the results are usually much better than with no test at all. Still in all it is the end user that really tests a product no matter how much you do in advance there will be breaks that occur. You can make the stuff fool proof, but you can't make it "Damn Fool Proof"tm
Scott
February 24, 2006 at 11:14 am
ding, ding, ding, ding... we have the winner!
Too much of that where I work.
February 24, 2006 at 11:28 am
We document new features and fixes before we write code, and our documentation must include a testing plan for the feature or fix. When the documentation is approved, we code it, and the testing plan is incorporated into the formal testing plan for the app. Granted, that testing plan has grown considerably as the app has gone through several upgrades, but overall it serves us pretty well.
We tried automated testing, but abandoned the project because maintaining the testing script was as time-consuming as maintaining the app! Human testers, following a formal plan on paper, gave us insights into how our interface was working for real people. Frankly, a lot of our bugs (and maybe a lot of bugs generally?) are just the programmer’s failure to anticipate and trap unusual choices made by end users. We wanted human beings testing, so we could find those “unusual” choices and trap (or accommodate) them before rollout.
February 24, 2006 at 2:20 pm
When I first started at my present job, there was no concept of user testing. It was basically the developer doing his own testing on his machine and then deploying directly production.
We had a few mistakes (I was to blame for some of them) in production and as a matter of self-preservation, I convinced my boss to give me two boxes for a test environment. One represents a user test workstation and the other is the test db server.
I also write up test instructions for the users and let them test any changes. They then have to sign it off before I move the changes to production.
Since doing this, I think we've only had one or two little bugs creep in to production. Most problems have been identified in the test environment.
I have also experienced over the years that the best testers of an app are the people that use it every day not the developers. I'm always amazed how easily users can break things just by doing things you don't expect!
February 26, 2006 at 11:34 pm
We do formal testing approach, however typically the tests only test what has been changed not what those changes might effect..however this is slowly changing with more support/qa personnel and more time dedicated to the testing regime..we also ask our users to install to their test systems and play with it there for a couple of weeks before they go live with it.
so we test twice in the lab (techies then qa) and once out of the lab (can't beat real world testing!)
our eventual move to dot net will definately include unit testing/test scripts. i think this will be the best advance in our companies testing procedures.
Cheers
------------------------------
Life is far too important to be taken seriously
February 27, 2006 at 6:41 am
All of our systems are configurable items, they require testing for everything, updates, patches, new software, cots etc. ATE would be great if the AI was far enough developed.
Viewing 8 posts - 16 through 22 (of 22 total)
You must be logged in to reply to this topic. Login to reply