distributedlife

A problem that plagues testing in immature organisations is keeping on top of environment changes. Quality Centre has releases and cycles but these are manual and useless. You have to rely on testers to change them. If they do not know about the changes that occur how can change the cycle?

The idea is to automate the process. I did this with a job that is scheduled to run at 1 in the morning. This idea is it would precede my service test runner so that tests were run against the new cycle whenever possible

The job will create a new cycle in a specified release using a configurable naming convention when one of the following occurs:

• A change occurs to the structure of the database
• An application is installed or uninstalled to one of a list of servers

A database change is required; a special table that records all events that occur in the database with respect to the structure. I then query these looking for changes that occurred in the previous 24 hours. If one has occurred I build a string indicating what has changed and create new cycle.

With the servers I look at each one and see what is in the registry with an InstallDate within the last 24 hours. If there is a new application we build a description string and add it to the new cycle description. This is the best way I’ve found to get new applications because it includes useful information like version numbers.

For uninstalled applications I look in the event log where an uninstall event has occurred. We are specifically looking in the Application event log and we want an Information event of type 11724. The event source is MsiInstaller.

I currently check for only MSI uninstalls.

I can’t recommend enough having an automated cycle changer. I find this approach better than continuous integration where every build is a change. In non-trivial integration projects not every successful build gets delivered to test. This is a reactive process that notifies you of changes the day after they occur. This way, when we get to work in the morning, we can see that a cycle change occurred yesterday and retesting can be done. When you couple it with automated test execution you have a test runner that is able to start retesting when a new change occurs.