I wrote a book with the friends the I wrote the cromulent testing blog with. We also published it ourselves.

It’s called What you need to know about dates and times in computing.?As you can probably tell by the title, this book explains what you need to know about dates and times in computing. Its sole purpose is to quickly get you up to speed on this ubiquitous and commonly misunderstood topic.

You can buy it here. The PDF version is a $3.5

One of the things I’ve really enjoyed is learning little things about places I want to go and see. In Malaysia on the island of Borneo there is a train route and a couple of the stations can’t be found in Google maps. They have a name and that is all. The rail site claims they stop there but from the terrain and satellite view it appears like a mountainous tree filled valley. I want to go there.

Another is the TranzAlpine train route in New Zealand that winds between mountains and by riverbeds. I’m sure it will be breathtaking journey.

To help with exploring, I have an upcoming feature that will show flickr photos that are within 10kms of a train station. Here is an example of how google does it now with panaramio.

One of the things I intend to talk about is blogging about the iterative design process of game design. What I learned from each attempt and some explanations on why I went for one feature over another.

Bookstores are going out of fashion in a bankruptcy kind of way. Is there value in a bookstore partnering with a ebook vendor, or all vendors, so that you can browse the shelves, find the book you want and then take it and the ebook reader to the front counter. The book is placed on your reader, the physical back on the shelf, the money then goes to the store, ebook vendor, publisher, author, etc

It would be in the interest of the ebook vender because you become heavily invested in their platform and it would be in your interest because your books are now consolidated in your shiny new device.

So I built trainlines.heroku.com

It’s an open repository of train routes. I’ve got regional australia, new zealand and hong kong, malaysia, singapore and the philippines on there at the moment. Google clustering takes care of visualisations at zoom levels so any level of route (metro, regional, international) can be supported but I do have an emphasis on regional and international routes. If you want to add a train route go right ahead.

If you can think of a suggestion to make it easier to use, let me know and I’ll consider it. For the meantime it’s feature complete (minus a few known issues).

For the testers out there that I know, if you feel the urge to break it, please go to trainlines-preprod.heroku.com and do your worst.

When I have the time, I’ll be using this space for all my non-testing adventures.

One of the key points about the learning objectives and the road maps is that they don’t instruct you in how to go about testing. The idea is to define what needs to be learned and to leave the how to be defined by context.

Here is an example learning objective from the automation discipline road map:

Understands how change impacts automation tests

This learning objective does not tell you how change impacts automation tests. That is outside the scope of what you need to learn. There is more than one way to write an automated test and each of these ways have pros and cons that impact the severity with which change will impact an automated test.

As the learning objective cannot document each and every way that change could impact an automation test this information is left for the tester to research and learn. How is that to be done? Research, books, blogs, peers, mentors and trail, error and practice. The same way we learn anything else.

The main goal of each road map is to help you identify what you can learn rather than telling you how to test. Start here if you want to learn more about testing.

The fundamentals description is: a set of learning objectives that support all disciplines of software testing. It’s the common techniques, responsibilities and concepts that we use as testers.

Here is the link to the current fundamentals information. In future the fundamentals will just be mentioned within the nine disciplines.

These are the eight starting disciplines of a learning framework that I hope will go a long way towards solving our three problems: a lack of direction, an information deficit and retention.

• Behaviour & Functionality
• User Interaction
• Business Domain Knowledge
• Management
• Performance
• Automation
• Infrastructure & Integration
• Security

I’ve covered these many times since first proposing my learning framework. For full details please go to this link. I’ll briefly summerise the disciplines for those don’t want to break the flow.

Behaviour & Functionality embodies traditional testing scope with an emphasis on the behaviour of the system. Behaviour is defined as the response of a system to interaction. User interaction is not covered here.

User Interaction covers testing the user interface, usability and the user experience. The user interaction tester knows that the success of a system extends beyond features sets and functional correctness and a system that helps a user achieve their goal can be more successful.

Business Domain Knowledge is about applying the testing skills set to the business domain. We ask questions like “what is the impact of software failure on business or on society as a whole?”.

Management is where the test lead and test manager exist and the skills they bring to the profession.

Performance is about looking at the behaviour of the system under a variety of controlled circumstances. Performance testing is not just looking at the implementation but covers architecture design, network topologies and infrastructure provisioning. A performance tester should be able to identify performance bottlenecks when they are designed rather than after they are built.

Automation covers both the facilitation of testing and the verification of behaviour. The verification of behaviour is limited to what can be easily automated; services, APIs, batch processes and web interfaces.

Infrastructure & Integration looks at the interactions between software components and the interactions between software and hardware.

Security weighs up the competing concerns of protecting against external vulnerabilities and allowing the users to be effective in the system.

The first four disciplines are non-technical while the latter for are technical. By technical I mean that a deeper understanding of the implementation if required rather than knowledge of a programming language. An important distinction to make as I know testers who are interested in technical testing but are not interested in learning programming, a common assumption.

In time these disciplines may split into more refined specialisations and they are not mutually exclusive. The more a tester knows about each discipline the more effective they can be. Each discipline is a way of focussing our thoughts into related topics. Next I’ll cover what is within each discipline.

[to be continued...]