Springe zum Inhalt

I have just uploaded the source code of my Motif interface builder to source forge. Anyone who is interested can find it at here.

In the current project the customer wants to have a simple Performance Compare Test. The customer wants to be sure, that the changes we made inthe software will not worsen the performance. Since the effort to make a full-blown load- and performance test is very high, this Performance Compare Test should be very simple.

The solution I found is the following: We will use Selenium IDE to record and play script. This script will be run on the old and the new version of the software. Because we only want to see, whether our changes have worsen the performance, this is acceptable. In Selenium IDE you have a button "Play with Selenium TestRunner". In this mode Selenium logs timestamps. We will use these timestamps to measure the time period it takes to click through the application. In the following image you can see the log from Selenium.

Selenium Log

The advantages of this:

  • Simple to install and easy to use, even on a developer's machine
  • The rendering of HTML and the JavaScript execution is measured as well

You still have to plan the tests, e.g. what test data you want to use and how do you want to click through the application. And of cause - this will not replace a full-blown load and performance test.

After having read "Getting Things Done" (GTD) by David Allen, I realized that one can merge the ideas of GTD and agile software development processes. In GTD David Allan proposes to have several goal level. The vision of life leads to long term goals, which leads to projects, and weekly goals and so forth. I've tried to match this idea to a process like Scrum. Starting from the bottom:

  1. During the daily scrum meeting the team defines a daily goal. This goal is influenced by the goal of the sprint.
  2. In the sprint planning the team fixes the goal of the iteration. If the iteration length is a week, it can be compared to the weekly planning in GTD.
  3. The project goal is formed by the product owner. The goal is not well defined, it's more a vision that is refined during the iterations.
  4. So - what's the next level. It's the strategic level. It's defined by the business vision and influences the IT strategy and activities in enterprise architecture.

If we introduce an agile process, we should address all goal levels. I think it falls to short, if the agile process is introduced only up to the project level. But how does the strategic level influence the project level? Do we need a stratigic backlog, like a product backlog?