So, your application gets deployed in a week. It has gone through system, integration, and user acceptance testing and has passed all three. However, the final phase (in our case, a few weeks before deployment) is that actual end-users (a much larger group than those who perform UAT) go through a 'business transition' phase where they are all trained on the new system so that they will be good-to-go when your pride and joy gets deployed to production.

We received a call a week before the production deployment that popups weren't working on some of our end-user's machines

The name that Oracle gave to the level of its ADF framework where the business logic is done is called the Application Module. It is from within this application module (and the view objects that it contains) that the database transactions and business decisions are controlled. Though the details of how ADF connects everything between the HttpSession and Application Modules are unnecessary for the purposes of these next few paragraphs, know that ADF essentially assigns an Application Module to the HttpSession when it is requested (for example, from an action class). However, it is not possible for ADF to have an infinite instances of each application module available for each user. Each user (read: HttpSession) will use only one instance of each application module that it needs (a unique identifer for this instance is kept in the SessionCookie). At the end of each HttpRequest, the application module is checked back into the 'pool'.

Are you new to a database schema and want to get to know it quickly?  It is very common for a system in development to interact with an existing system and all too often, the requirements for this interaction are vague and difficult to understand, and gaining knowledge about this (potentially very old) system can be even harder.

Of course, there are tons of ways to learn about a schema.  Old school DBA’s may prefer to do manual queries on the views of the database metadata (all_tables, user_tables, all_objects, etc) to get an idea of how it works.  People not as familiar with such ‘DBA-esque’ things may have a hard time extracting an understanding of the data model using nothing but queries.  Often times, it might be easier to get an understanding using such tools as Toad and SQuirreL.  I just recently found a tool called SchemaSpy that can answer a LOT of questions that a ‘newbie’ may have about a schema.

You’re going to have to fix stuff.  Along with there being unforeseen defects in the system, there is going to be corrupt data that needs to be corrected.  There are essentially two kinds of corrupt data – the first is wrongly entered by the system, and the second is wrongly entered by the users.

The first will hopefully be kept to a minimum as a result of good requirements (and interpretation), development, and testing.  However, it’s not a perfect world, and in addition to the corrupt data being corrected, there will be defects in the system causing them.  It goes without saying that these defects must be addressed.

A basic overview of Rational’s automated testing tool, Robot, is that it records the user’s actions in a VB-like script that can be played back whenever the user requests.  This recording is done through the UI – and so it can only be done after parts of the application have been developed.  Since it will be used as a baseline for regression testing in later release cycles – it shouldn’t be written until that part of the system has been tested.  Robot scripts can be quite powerful, and the user can create ‘verification points’ to test to make sure that the data in a certain drop down is accurate, business results are correct, or even compare screenshots of the application to a baseline to make sure that the UI hasn’t changed.  While great for regression testing when no changes have been made to parts of a system, it may not be the most efficient way to test in an iterative development environment.