Generating Data with PHP

Pretty much claim to have forgotten how to handle a piece a code to be almost immediately jogged by a short search. Anyway have completed the string generator in PHP. Possibly the most interesting point of the exercise is the strings that are created - some are just plain weird.



The weirdness is possibly the main attraction especially if one is not limited to boring strings like alphabetical and alphanumeric - although a quick random ASCII will show if there are any problems. I extended my initial release to include generating printable ASCII in addition to using the full ASCII encoding. This means that the string offering is only missing the unicode option.

I would say that just writing the generated string straight to the web-page, does not result in the prettiest of output options but it serves the purpose (at least for now).

Restart on PHP

After a few years I've picked up on PHP again. I'm reminded of how powerful a language it is - as well as how much of it I've forgotten.

My primary goal in this exercise is to be able to generate random values that can be used as test data. I started with a class for generating random strings (alphabetical, alphanumeric and ASCII) along with various formats (all capitals, all lower, sentence, title and random) as either of fixed length or of random length within a range.

This was relatively simple. The issue and where the memory hole exists is in processing input so that the values can be generated as needed. I remember processing the POST variables as well as doing input validation with error messaging. The solution is probably quite simple, I just need to finish this before moving on to the next bunch of ideas.

Data Generator

Data is probably the most important part of any application test.

Imaginative data is more likely to locate the bug than its more conventional friend. However, creating weird data can take a lot of time. To alleviate the strain, I've added my 2c to the field with a macro driven Excel spreadsheet.

There are drawbacks to the approach I've taken. The first of which is that it is scripted in Excel. The second is the number of codes that I needed in order to all the options that are included. The codes themselves aren't too complex, but there are enough to make remembering them a problem.

Reporting in a Technical Area

Reporting where the project is and what you've been doing is a common feature within a development project. Reporting is however not something that's liked since it takes up too much time (among other reasons).

Personally I track what I do in a TiddlyWiki. More than that seems to be redundant. The basic features of a Wiki make it a great tool for tracking what you do on a project. As a notebook it is superb and then adding the cross references (links) and index (tags) it surpasses any solution I have tried in the past.

However good this as a personal solution, it doesn't cover the needs of management. The often rigidly formatted documentation can be a real pain to work through as format constraints often exceed usability.

In consideration of this, as well as finding myself in a position with a sudden need for a status report from others, some reasonable solution had to be found. Among the things I'm experimenting with is a near-agile test automation development process. Of the things within the agile development world I've pulled in are the cycle and the need to plan what to do in a cycle.

My original idea was to use a two week cycle. This did not tie in with the classic development processes adopted outside of our group. As such I've switched to a 1 week cycle which is way too short, but it does mean that there is a synergy between us and the rest of production.

With each cycle is the associated planning for the cycle. The planning is a simple top-down approach - task with sub-tasks. The tasks and sub-tasks are prioritized (high, medium, low) and scoped (short, medium, long). This information forms the basis of the ultimate report.

For now, I've put the planning in an MS Excel file and supported the basic actions with macros. The macros pull the data from the planning cycles into a formatted template. The priority and scoping data is being used to generate an approximation of the actual effort - total and remaining.

This seems to be an effective solution. Planning is a good thing which is being positively reinforced by the least-effort status report. I just need to put some more thought into the effort estimates as well as into some additional efficiency options.