Web Project: catching up

Time to bring you up to date on our web testing efforts.

The test system was running well on Thursday, so I was able to work from my desk to complete the testing Tony needed me to accept. Everything worked, though there were some performance issues which I suspect are specific to my desktop. I recommended to my boss that we approve the newest changes for promotion to the production system so our beta testers could see them. Then I documented the other issues Sarah and I had discovered on Wednesday.

This is a good place to be, by the way. Tony’s coders have now addressed all the heretofore problematical architectural and document delivery issues. The remaining issues are implementation details–screen design quirks, failures to transfer data to the back end, that sort of thing. We can work this out….

Yesterday all sorts of thing happened:

  1. Our IT coders promoted their code to the production environment.
  2. The back end’s vendor promoted related code changes.
  3. Our network people reconfigured the back end system’s local sub-net.

Naturally, this didn’t quite work right, but they seem to think they’ll have it under control by the end of the work day.

Sarah and I completed our run through the User Acceptance tests yesterday, too. It’s my well-considered opinion that the best test sessions are pretty boring; this one qualified. We found a “feature” which a reasonable person would say works better than the spec; unfortunately, we need it to work like the spec, which echoes the relevant law. We also found a couple places where the forms we’re creating are missing some data the app actually requests, which is the sort of thing you expect to find in this environment. I documented those this morning.

So: Where are we?

  • A bit over a year late.
  • The necessary hardware and software infrastructure is in place.
  • There are a few remaining program issues:
    • Three are preventing making the app available to the public (two should have easy fixes; the third still needs to be evaluated).
    • A half-dozen need to be fixed soon after we go live, if not before.
    • Another dozen or so need to be fixed as the programmers find the time.
  • We have a number of second-generation changes identified, including a total redesign of one of the program segments.

This is manageable. After a year devoted mainly to solving one problem, we begin to see the project’s end….

This entry was posted in Bureaucratic Whimsy. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.