On the management of software projects:

Programming management will continue to deserve its current poor reputation for cost and schedule effectiveness until such time as a more complete understanding of the program design process is achieved.

We build systems like the Wright brothers built airplanes — build the whole thing, push it off the cliff, let it crash, and start over again.

Production of large software has become a scare item for management. By reputation it is often an unprofitable morass, costly and unending. This reputation is perhaps deserved.

On the distinction between design and production:

Software production takes us from the result of the design to the program to be executed in the computer. The distinction between design and production is essentially a practical one, imposed by the need for a division of the labor. In fact, there is no essential difference between design and production [...]

The most deadly thing in software is the concept, which almost universally seems to be followed, that you are going to specify what you are going to do, and then do it. And that is where most of our troubles come from.

On dealing with user requirements:

Users are interested in systems requirements and buy systems in that way. But that implies that they are able to say what they want. Most of the users aren’t able to.

We should have feedback from users early in the design process.

On programmer performance (compare with the essay Great Hackers by Paul Graham):

I have a question on the huge range of variability of programmer performance. Are similar ranges found in other engineering areas? [..] The variation range in programming is in fact greater than in other fields.

On the production of software:

We are starting gradually, and building up. My motto is ‘do something small, useful, now.

Large systems must evolve, and cannot be produced all at one time. You must have an initial small core system that works really well.

On testing software:

System testing should be automated as well. A collection of executable programs should be produced and maintained to exercise all parts of the system. [...] As an output of a test validation run, each test should list the modules it has exercised, and as well, should list the interfaces and tables it has tested. It is important to document success, as well as failure.

Someone delivered a really poor software project for our tax money. I would love to redo the european legal information website with proper standards (e.g. validating HTML, RDF and proper semantics).

Oh well…

It is amazing how much you can improve the percieved site speed by some minor changes to your htaccess file. This site runs WordPress and I was tempted to install the WP-Super-Cache plugin but was put off by some of the incompatibility issues that were reported with the latest version of WordPress and PHP safe mode. Until then I managed to lift my YSlow site score from grade F to grade C by:

1. Removing ETag headers by adding the following lines to my htaccess file (outside the wordpress-specific rewrite area):

Header unset ETag
FileETag None

2. Setting a future expires header for static files by adding this to htaccess:

<FilesMatch "\.(ico|pdf|flv|jpg|jpeg|png|gif|js|css|swf)$">
Header set Expires "Thu, 15 Apr 2012 20:00:00 GMT"
</FilesMatch>

If your app/blog uses some sort of dynamic generation of images you can modify the matching rule above for a more precise selection of files (e.g. only files in the templates folder).

Presto! Two simple additions to htaccess and cached access is down to two requests (of which one is Google’s javascript file for ads):

The typical response seem to be status 500 (internal server error) on a lot of IIS sites. So, now is a good time to check your own sites to see what you get back from a:

curl --head http://www.mysite.com

This means that there is no reason to skip basic accessibility testing of whatever you are developing! To find out more on how you can integrate Raakt in your testing framework check out the Raakt wiki which now has a lot more information.

To install the new version simply type gem update raakt or gem install raakt if you have a previous version installed.

Changelog

Summary of changes from version 0.4 to version 0.5.1.

• Example of how to use RAAKT in Watir unit tests.
• Tests for area element alt attribute.
• UWEM mapped in comments for relevant test methods.
• Test to check that input fields of type image have an alt attribute with text.
• Refactoring of some methods for more compact syntax. Patch by Derek Perrault.
• Added test to verify that fieldsets have legends.
• Fixed alt_to_text that needed to check element type before attempting to read attribute value.
• Fixed language attribute check (downcased value). Added iso language code list.
• Applied patch from Derek Perrault (better use of Hpricot features).
• Fixed check for lang attribute (now requires a value as well).
• Test for charset mismatch in http headers and document meta element.
• Switch to Hpricot. Patch by Derek Perrault.

An article on the value of, and how to integrate basic accessibility tests in your development process is in the works for standards-schmandards.com. In the meantime check out the Raakt wiki.

If you are using Watir it is very simple:

require ‘watir’
require ‘raakt’
require ‘test/unit’

class TC_myTest < Test::Unit::TestCase
attr_accessor :ie

def setup
@ie = Watir::IE.start(“http://www.peterkrantz.com”)
end

def test_startPagePassesBasicAccessibilityCheck
#set up the accessibility test and pass html to raakt
raakttest = Raakt::Test.new(@ie.document.body.parentelement.outerhtml)

#run all tests on the current page
result = raakttest.all

#make sure raakt didn’t return any error messages
assert(result.length == 0, result)
end
end

Typically, developers tend to forget to turn off view state resulting in a lot of data that never is used. The guy who made the decision to have this default view state behaviour has probably caused a lot of unnecessary bytes clogging your internet connection (as it typically is included in each request).

If you are using mechanize and/or Hpricot to parse such a site you may have come across this error:

ran out of buffer space on element <input>, starting on line 38. (Hpricot::ParseError)

If you want to try it out, load this sample viewstate file into Hpricot. The buffer space error has been reported in the Hpricot issue tracker.

Fortunately, from version 0.5 of Hpricot it is easy to increase the buffer size before loading data. This is done by setting the buffer_size attribute to a sufficiently large number:

require ‘hpricot’
Hpricot.buffer_size = 262144

Fixing Mechanize

As mechanize uses Hpricot as the default parser this error will happen when loading many ASP.NET pages. Fortunately, mechanize allows the user to specify a custom parser class through the pluggable_parser attribute. To make mechanize use Hpricot with a larger buffer size:

require ‘hpricot’
require ‘mechanize’

Hpricot.buffer_size = 262144
agent = WWW::Mechanize.new
agent.pluggable_parser.default = Hpricot
agent.get(‘http://www.peterkrantz.com/wp-content/uploads/2007/02/viewstatesample.htm’)

…and we’re back on track mechanizing the world again.

Jonas Bengtsson has created an initial version of a Selenium plugin for RoR.

I have been using Selenium for a while now and this certainly looks promising. There are some minor details in this release that need to be fixed such as coloring of completed test actions and test cases (mine are not highlighted). A nice addition would be if RadRails supported code completion of selenium actions.

Setting it up for an ASP.NET application is done in a few simple steps:

1. Download Selenium (choose the full install).
2. Create a folder “selenium” in your web site root folder.
3. Unpack the zip file and move the selenium files to to the selenium folder.

That’s it! Selenium is now installed. You can test the installation by running the Selenium self-test by pointing your browser to http://localhost/selenium/TestRunner.html. Selenium runs in your browser of choice and there is nothing more to install.

Creating your own tests

Getting started with your own test suite is easy. A test suite consists of one or more test cases. A test case consists of a series of commands and verification points which you specify in a table in an HTML file. A sample test case looks like this:

<table>
<tbody>
<tr>
<td colspan="3">Test search query</td>
</tr>
<tr>
<td>open</td>
<td>/default.aspx</td>
<td></td>
</tr>
<tr>
<td>verifyTextPresent</td>
<td>Welcome to the sample search application</td>
<td></td>
</tr>
<tr>
<td>type</td>
<td>StartpageFramework1_QuickSearch1_txtSearchPhrase</td>
<td>ultramarine</td>
</tr>
<tr>
<td>clickAndWait</td>
<td>StartpageFramework1_QuickSearch1_btnSearch</td>
<td></td>
</tr>
<tr>
<td>verifyTextPresent</td>
<td>No match found</td>
<td></td>
</tr>
</tbody>
</table>

It should be fairly obvious what this test case does; the page default.aspx is opened in the browser, the text “Welcome to the sample search application” is identified, “ultramarine” is typed into the search box field, the search button is clicked and then we verify that the text “No match found” was displayed.

As you can see, the type command needs a way to locate which field to type the text into. The easiest way is to use the id of the HTML element (there are other ways to locate an element). If you use runat=server controls ASP.NET will have generated the HTML element id for you and depending on it’s position it may look something like StartpageFramework1_QuickSearch1_txtSearchPhrase. Unfortunately the id will change if you move the search field to a different container. This would force us to update the test case every time we did minor changes to the page.

Thus, a better way to identify fields and buttons is to use an XPATH expression:

//input[contains(@id, "txtSearchPhrase")]

This will make the test case independent of control hierarchy changes.

After you have saved the test case to a file (name it “searchtest.htm” and put it in the selenium directory for now) you can create a test suite where we point out one or more test cases. A test suite is also described in an HTML table like this:

Each test case in the suite is identified with a link in a single table row. Save the test suite (name it “searchsuite.htm” and put it in the selenium directory).

Run your tests

Now it is time to test your application. To open Selenium with your test suite, point your browser to http://localhost/selenium/TestRunner.html?test=searchsuite.htm and start it. You can follow the progress as the test is carried out.

Next step

All in all Selenium is a quick way to get started with automated functional testing. Apart from opening URL:s and verifying text fragments Selenium is also capable of handling javascript dialogs, variables, continuous testing/reporting and many other features. For more details see the Selenium web site.

You can also combine Selenium with NUnit to get a complete testing environment. Instead of running test cases in the browser it is possible to install the .NET test driver which gives you control of the browser process via .NET code.

More information

• Selenium for functional testing of a Ruby on Rails and Ajax application
• Record Selenium scripts in Firefox