Page History

...

• Implement the support packs and enhancements in a sandbox/prototype environment first to get a better idea of the impact and time needed
• Start review/analysis of the support packs already received earlier - don't perform testing until all are received
• A spreadsheet is not the best tool for keeping the information needed for testing; a DB or other tool would be helpful
• Have an environment with the changes applied available so development can continue
• During the implementation, please don't move status calls earlier without at least an hour's notice
• Extended team meetings were not conducted frequently enough
• Information dissemination was pushed down to the individual functional teams, didn't come from one place
• Many individual test scripts still not updated
• I had responsibility for approving UAT for some business areas due to staff turnover
• Confusion about when UAT ended
• Confusion about what could be tested during period end closing
• Confusion about the intention of SIT / UAT
• Business owners were told they did not have to test during UAT; they could accept the results of SIT as UAT; created a mess that had to be re-communicated at length
• Not enough communication
• Scheduling of users during UAT wasn't done consistently; given a time period and a deadline and told to meet it; created lots of uncertainty around the deadline
• One area that I don't think came out clearly in Friday's meeting was the need to track Transaction Testing (unit test items) and Test Cases (SIT items) in a db as opposed to spreadsheets. The spreadsheet approach forces us into multiple versions, file manipulation and inconsistencies in tracking amongst our groups. If we used a db and initialized it with this past SP testing data our tracking and updating would be much more efficient.
• The other area that needs improvement is Action Log. This log needs to be a little more explicit in what needs to take place in which environment.