Archives for category: Misc

It’s fair to say that Australia’s Attorney-General, George Brandis, has been struggling to explain what he means by metadata:

Brandis: “The web address, um, is part of the metadata.”

Journalist: “The website?”

Brandis: “The well, the web address, the electronic address of the website. What the security agencies want to know, to be retained is the, is the electronic address of the website that the web user is … “

Journalist: “So it does tell you the website?”

Brandis: “Well, it, it tells you the address of the website.”

It appears that Brandis is trying to explain the difference between the address of the webpage (the URL) and the numerical address of the computers serving up the webpage and accessing the webpage (the IP addresses).

If so, then there are a couple of problems with the Government’s proposal:

  • a single IP address may serve web pages for many different and unrelated websites.
  • a home user may have many different IP addresses over time

For example, this webpage is hosted by WordPress, as are many many other webpages.  WordPress uses the URL to know which website to serve, not the IP addresses.  Indeed, WordPress use many different computers with many different IP addresses.

Furthermore, and there are exceptions to this, but most home users, when they connect to the internet, will be given a different IP address each time. There are a finite number of IP addresses, and this may change in the future, but at the moment, common current practice is for ISPs to share IP addresses between customers.

As described, the government’s proposal will not work.  To know who is visiting what website, more than just IP addresses are required.

I attended a Sydney Tester’s meetup yesterday: Help … Can you solve my testing problem?

Three attendees volunteered problems that were discussed:

  1. What is the role of a tester on an agile team?
  2. How to retain motivation in a challenging environment?
  3. How to test in a multi-tier environment?

1. what is the role of a tester on an agile team?

  • key issue: even on an agile project, management still need to be able to track (at least approximately) the percentage complete/to-go for the current sprint
  • discussed: ways of logging exploratory tests on the fly – for audit purposes, and as potential input into formal test cases
  • identified: test phase squeeze is an issue – coders overrun schedule => testers get squeezed
  • suggestions: involve testers earlier – when specifying user stories; move some testing responsibility to coders; various ways to predict effort required.
  • open issue: how much documentation is ‘sufficient’?
  • open issue: test automation should save time, but how to find the time to automate tests?

2. how to retain motivation in a challenging environment?

  • investigated: if overwork is the issue – concluded no
  • workplace specific issues: inexperienced developers
  • key issue: determined that test fail rate is very high – approx 75% of tests failing – led to discussion of ways to ‘train’ developers, also led to speculation that tester may be aiming for a higher level of quality than customer actually wants

3. how to test in a multi-tier environment?

  • key issue: tests depend on data which is pulled from/pushed to a chain of other systems which are not under projects control
  • noted the risk that available data will drive test selection instead of the other way around
  • suggestions: automated searching of data set for usable data, mocking data in database, mocking data by capture and replay at external interface.

Interestingly, at least two of these problems are people problems, not technical problems. The solution will lie in realigning someone’s expectations – perhaps everyone’s.

Comparing OSDC  (the Open Source Developers Conference) with iqnite (the conference for professional software testers), if you guessed that OSDC would be ‘cooler’, more hard-core and more feral than iqnite, you’d be right.

If you also guessed that OSDC would be less concerned with matters financial, you’d be wrong. Money was explicitly discussed far more often at OSDC than at iqnite.

To understand why, remember that the typical iqnite attendee is a professional at a VBC (Very Big Company), quite likely to be concerned with the effort estimates, schedules, and targets, all of which have dollar implications, but only indirectly. Further, that concern is usually local, often not going beyond the person’s own contribution. As the old saying has it, “The operation was successful, but the patient died”. Or, as a salesman once said to me “I don’t know if the projects I sell make a profit. That’s not my job.”

On the other hand, a significant proportion of OSDC attendees are small business owners, precisely because they have a passion for technology but – ironically – to survive as a small business person requires a constant focus on the financials. Or they are running, and funding, Open Source Projects.  Therefore, there were topics such as: “How to sell, for geeks” (Giri Fox), “Small Business Mistakes” (Jacinta Richardson), “Free as in Kittens v2.0″ (Evan Leybourn) and “Blood from Stones: Asking for money for your project (Cat Allman).

A theme common to both conferences was the move away from bespoke development from scratch, towards building on (integrating) off the shelf packages. Paradoxically, as the utility of 3rd party platforms increases, so does the number; it becomes simultaneously more necessary and more difficult to keep track of new developments in any given field.

And of course, there were robots. There was a 3D Printer. There was a mind-controlled mouse. As one speaker put it, “the future is here”; all of these things which used to be science fiction are now affordable by hobbyists and will eventually be every-day items.  If you were at OSDC 2012, you saw it first.

One more thing. There has been a turnover of the OSDC executive committee – so expect some changes and improvement for OSDC 2013.

No scripts in this post, just a quick review of what was topical at iqnite 2012, the software quality and testing conference. Read the rest of this entry »

For the testing of servers

If the only tool you have for testing your server is a GUI, you are going to be embarrassed occasionally. Read the rest of this entry »

A simple calculator

This is a simple calculator that sits in the gap between feature-light programs like windows calculator and the high overhead of a full on spreadsheet. Read the rest of this entry »

For the testing of clients

When developing a client application, it helps to be able to test it.  Sometimes, testing against a real server is enough.  But at other times using a real server will slow you down, either because a real server isn’t available, or because you have more coders than real servers to test against, or because it takes time to set up the server for each run, or simply because you want to test behaviour a real server doesn’t normally display, such as error conditions.

In such cases and many more, you need a mock server.

Enter Read the rest of this entry »

Wherein we debug what we started  earlier.

If you ran the example at the end of the post you would have seen a blank screen.  Excitement.

But why?

Read the rest of this entry »

Monitoring communication between a client and a server is one of the oldest scripts I’ve written that I still use, and I still use it regularly.  Some of the other scripts I will share depend on this one, so it seems like a good place to start.

At its heart, it is incredibly simple: Receive a message, keep a copy and pass it on. Read the rest of this entry »

This is, or will be, a collection of tools (scripts) I’ve found useful for testing or debugging or for some other purpose.

Most of the scripts will be in perl, at least at first.  I’ll try to explain how they work, and how to use them. Maybe not always both at once.