The Secret Diary of Han, Aged 0×29

Han said: We could delete the dcaft database altogether to free up more space.

What is the dcaft database?

“Decimate originally referred to the killing of every tenth person, a punishment used in the Roman army for mutinous legions.”

Grig Gheorghiu has an interesting web log on testing in Agile development. Also contains a lot of good stuff on the two test tools I mentioned.

When I tried SourceForge today, it said it could not connect to the database. I looked at it, and the disk was full (again).

To fix it, I shut down oracle (/etc/init.d/dbora stop), edited /var/opt/oracle/oratab to stop the dcaft000 database from running. I then started oracle again (/etc/init.d/dbora start). Finally I removed the redo logs on the dcaft database. Disk space is now at 92%. We could delete the dcaft database altogether to free up more space.

Sourceforge is running OK again.

These tools looks pretty good for validating the GUI. I haven’t tried to use them with Siebel yet, but I should have a chance next week. The toos that I looked into had modules specifically for Siebel 7, but are general purpose web app testing tools as well:

Quick Test Professional: This one is from Mercury–pretty much the industry leader in automated testing. It’s high end but is pretty easy to use. You train it by recording user actions as opposed to writing scripts (which is also possible). It has a Siebel option. There would be some learning curve involved. I looked at it a while back but I could never get a demo copy of the Siebel module from Mercury.

Empirix e-Test: Looks pretty cool. Maybe a little bit of scripting involved, but they advertise no coding. Has Siebel module. The suite comes with load testing and test case management tools as well. I’m going to look into getting a free trial.

Scriptmap: This one takes a little bit different approach. Says it uses requirements to drive the tests instead of recording user actions. The site is an interesting read. Looks like it is mainly geared towards Siebel–at least they spend most of their time talking about Siebel on the site.

Segue: Looks like if you buy the Siebel suite, you pretty much just get that. Says they are a Siebel alliance partner…

I’m going to try to download and test some of these if possible to see if they might be a good fit. I’ll keep you posted.

I searched around for useful testing tools last weekend. One reason is that the QA team will be decimated soon. After next week, it will basically only be Takagi-san and Xiaomei. Clearly, unless we have some automated test tools in place, QA will only be able to test a fraction of the developed functionality. I assumed we need the following:

1. a browser UI testing tool
2. a functionality testing tool

The main requirement for these tools is that the QA team can create new tests themselves without (much) coding, and that the tests are readable and self documenting.

There is quite a bit of good stuff out there. I found the following the most interesting:

Selenium

This is a tool for testing GUI’s. It works through a browser based Javascript framework, and takes its test cases from HTML tables. It works with IE and Gecko browsers. The nice thing about this setup is that, since it runs in the browser, it supports Javascript properly, which is where many other webtesting tools suffer. Plus it is free. I played around with it a bit and created a small demo test for the Operator portal. It supports multibyte properly. I haven’t tested it with Siebel yet. The tool does not need to run from the browser. It can also “drive” the tests from C# or Java code. But the browser-based mechanism seems the easiest to use.

A GUI testing tool is good at checking whether the GUI is in order, but it can test the underlying functionality only indirectly, through GUI actions. Therefore we should also use a functionality test system to test the logic. I had a look at the following tool.

FitNesse

Like Selenium, FitNesse uses HTML tables that contain the test cases. FitNesse is also a Wiki, so that it is really easy to add and change the testcases from within the framework. In contrast to Selenium, it needs some development support. Some glue code (”fixtures”) is necessary to connect the HTML tables to the code to be tested. But once the fixtures are written, tests can be added very easily, and the overall result is a set of automatically executing, nicely documented functional test cases. This tools supports both Java and C#.

Lunaris is back in the land of the living. Booting into safe mode and running a chkdsk on C: did the trick. The drive has plenty of empty space, so that is not the problem. We restarted Siebel to get that to work again.

C. will migrate the Siebel DB to a Solaris 9 machine. This means the Siebel DB will get more stable, and we free up another G2 for development work.

Today a meeting was held on Cycle 11, organized by the QA team and the Operation team. Their intention was to hold a planning meeting for cycle 11, and to start development using the development flow as written up by S.-san.

In a meeting on Jan 24th, however, I already presented the cycle 11 plan and got approval for it, and currently we are 2.5 weeks into cycle 11 development. I therefore said that the meeting should be considered a requirements/planning meeting for cycle 12 instead.

We then discussed a list of requirements from customers, mainly for CDS. Most of the items on the list will be considered for cycle 12. One item described a bug that was already fixed, and one item was rejected.

We then discussed a list of issued and requests from the QA team. Some of these are already being addressed in cycle 11. Others will be done in cycle 12 or later. All issues are fairly small items.

Today I created the following branch in CVS:

1-5-0-branch

This branch contains code changes for cycle 10 bug fixes during the QA period, end bug fixes for cycle 10 once it is in production. Cycle 11 stuff should be checked in to the head, as usual.

Just to be clear, here is the CVS branching and tagging flow:

1. When a development cycle ends, the code is tagged [major]-[minor]-0. This tag represents the original code deployed into Staging. For instance, for cycle ten this is tag 1-5-0
2. At that time a branch is created called [major]-[minor]-0-branch. This is the branch that bug fixes during QA should be checked into. For example, in cycle 10 this is the branch created today 1-5-0-branch
3. When QA is finished and approved,and is released to production, a new tag is created on the branch: [major]-[minor]-1. This tag represents released production cycle code. For cycle ten this will be 1-5-1
4. Whenever a bug fix is released to production, the code on the production branch will be tagged with the next increment of the release number. For example, the first bug fix released to cycle 10 production code should be tagged 1-5-2. This is to ensure we can always reproduce the currently deployed production code in development.
5. In the mean time, development on the next cycle continues and changes are checked into the head. When the cycle ends, and the code is deployed to production, it is tagged with the next major or minor version number, e.g. 1-6-0, and a branch is created for bug fixes to this tag: 1-6-0-branch

Per March 1st the organization was changed again. The biggest change is that the Opsware team has ceized to exist. K-kun and other members are now part of the server team, which was renamed “system” team.

the big O-san is now a member of the tools team. The tools team is now responsible for Opsware as a tool. The system team takes care of OS packaging, patches and deployments.

The QA team has also ceized to exist as a separate team and has been added to the tools team. The main people in the QA team will be X and T. S will advise the organization of documentation and QA and development process.

Finally the former process team, that was more recently renamed coordination team, is now renamed business QA team, although I also saw the name process QA team at least once.