invoices

It seems every different agency I work for has different rules on invoicing - some like the contractor to invoice per calendar month ie 1st Jan to 31st Jan), whereas others like us to invoice up to and including last Friday of calendar month (so based on weeks).

I would much rather invoice on a calendar month, as it's pretty easy to remember where you invoiced up to last month. On a 'weekly' type system, always have to check the previous invoice, and make sure there is no overlap. Argh! Come on agencies, contractors are providing YOU with our services, not the other way around! You're making a cut on everything we invoice, and all you have to do is sort the inital contract and interview, and get me my money each month. If the IT industry in London wasn't so fixated on using agencies, there would be no cut for the agency, so how about you accept invoices in whatever format the contrator prefers huh?

(wow... first rant i've posted for ages!)

The king is dead, long live the ...

An old workplace of mine has gone into receivership. Pretty sad really, as I met a lot of great people there, who I still see every now and then.

These guys gave me my first insight into the software world - they worked us hard and long, and there were a few tears here and there, but all up it was an experience that I think has helped me in the long run.

The software still lives, tho under a different company, so there is a little bit of my influence still out there in the world :)

My Previous Life

Just googlin to see if I have any image credits picked up by google on the big wide internet, and came across a newsgroup message archived, from my previous life as a biochemist:

I am currently doing assays of protein in cell cultures, and am looking for a good method of lysing human and rat cells which are adhered to 96-well plates, before measuring luminescence. Currently using five minute freeze/thaw cycles, but am looking for a better way.

Thanks
Rachael Russell
ESR
Kenepuru Science Centre
New Zealand

http://www.bio.net/bionet/mm/cellbiol/1999-June/010937.html

Wow... I can't remember posting this message, and I can on vaugely remember what I was talking about. I do miss messing about in the lab and getting (barely) paid for it!

Test Management in JIRA?

From the i'm-frustrated-with-excel-spreadsheets-to-manage-testing department.

The lack of reasonably priced, extendable and usable (big feature for me!) Test Management tools is starting to annoy me... Test Director/Quality Center is too expensive for most places I've worked (you'ld think an Investment bank would be able to afford it but no! They are looking at some weird thing I've never heard of, so could be badly supported yikes!), and requires too much training/maintainence for a 'looseish' UAT process like we have here (ie there is a process, but too many people push outside it due to time restrictions and lack of testing knowledge). There are cheap/free alternatives around that I've tried, but they all seem lacking in lots of functionality, or just plain unsuable and inflexible.

I think JIRA (change/defect management tool) could probably be extended to include a Test management function --> if it had that, it would do everything that Test Director/Quality Center does excluding the linkages with automated testing (ability to schedule and fire off tests created with winrunner/loadrunner/QTP/Silk(?) and probably others), and would really help with the whole 'integrated' change management Suite if you don't care about running automated tests from the UI.

For sites that don't use automated testing, or automation platforms that don't play nice with Test Management apps, it could then provide a low(ish) cost 'total' change management system that hooks into scm also... mmmm dream on Rach!

A Test Case is not so different from the usual workflows - but it usually doesn't get 'closed' in the same manner as bugs/changes, and need to jump around in history against versions of test cycles (ie for regression testing). Then store results of testing and easily raise bugs/changes (mmm) on failures etc. From there, it's not a huge step to add requirements mangement also - as the linkages/relationships between requirements, Tests and Changes (defects etc) aren't all that different. Drop some reports into a dashboard specifically for Testing/Requirements, and bob's your uncle.

One day I'll do myself a el-cheapo Test & Requirements Management app (in Access if I'm desperate, or Java/JSP or something - might as well try to extend JIRA if I'm going that far, and if Atlassian still supply source code for your own tweaks :)) so I can work out the workflow/requirements of a good app myself, as I've never quite found one that does everything I want. Hmmmm wonder if Atlassian are lookin for a contract User Interface Designer/Business Analyst type person workin in London at London rates!

That's todays <rant/> for ya :-)

I heart JIRA

I am so missing JIRA, the issue management tool I implemented and championed at Virgin Travelstore a few years ago. I miss lots of things:

• Ability to schedule fixes into releases
• Sensible workflows
• Built in graphs/reports that work
• Assigning tasks to groups rather than people
• rss feeds (!)
• Exporting to csv(excel), pdf, can't remember other formats
• Usability! So easy to use compared to some other tools
• and lots more stuff that I can't even remember right now....

Haven't found another tool that works better yet for change management. Stuck with MKS currenlty (yeah I'ld never heard of it before!) and ClearQuest in my previous contract. Tried Test Director/Quality Center, but that still doesn't seem so powerful.

Fit/Fitnesse

Fit/Fitnesse (http://fitnesse.org/) has been adopted by some projects at my current job for 'automation' testing in the UAT process.

Now I can see automated testing is needed in UAT, esp useful for regression testing. However the Fit/Fitnesse framework only works for java based apps, and hooks in at the class level. A big problem with it, is it requires java developers to write the tests.... so there's stumbling block number one -- business users aren't java developers - so either grad students (who work a few days a month if we're lucky), or external consultancies are used to build these tests. How they are maintained, I have no idea!

IMHO (and in most of the software testing world!), UAT should be testing end-to-end business processes, not messin about with the java code. When using an automated tool, it should interact with the UI, as this is where the end user interacts with the software. Often a business process will jump into various different apps, or even paper/offline processes.

To me, this seems too much like low level testing that is done at unit/integration or system test phases. Note the 'U' in UAT stands for 'User'. If it's not simulating user interaction, it ain't a UAT test.

lowest tech possible

I bet pretty much nobody in the city could undercut my lowly tech situation at work:

I'm running:
- 15" lcd - max res 1024*768 (true color luckily!)
- ye old worldie clicky compaq keyboard and clicky clicky scroll wheel mouse (ball type, not optical)
- locked down Win XP pro - no command line, no mappin network drives, no installin anything without seven months of testing by the IT admins first
- telnet sessions on Unix servers (via some 1980's lookin windows telnet
client).

mmmm lucky me :-)

Random software development

So we keep getting new versions of code to run in UAT. Only problem is -- no release notes. Nadda. Nothing. Just a list of code modules that need updating, which means nothing to me!

Who has a development contract that doesnt include the supplier sending release notes? Or at least a napkin with some scribbed bug numbers on it that's been left on a pub table for much too long..? It means UAT testing (which is the only testing actually carried out... don't get me started on that...) has to have a random guess at what might or might not be fixed, and no idea on any impact on the rest of the system. So bye bye to any regression testing. Rather frustrating for me attempting to manage the UAT process, no?

[Edit] Turns out I can't find requirements to match half the bugs logged. Hmm, so there's issues from both ends at not supplying what's needed for a good development project.. Requirements and release notes.

Am I mental?

Really struggling today with my fav app in the whole world, Lotus Notes... I can't work out how to get my meeting to remove one guy and swap him with the guy he's delegated (Notes has sent me an email to say this guy was delegated to the meeting)... Is it just me? Is it impossible? Do I just have to 'remember' that someone else is coming in his place?

Also can't get a printout which includes everyone in my meeting... really frustrating - have to print out the meeting, then write in all the names that are hidded in the textarea/scrolly box. Am I missing something again?! [Edit] Found it! Under Print Page Setup there is an option (off by default...) to expand the names field. Why oh why would this not be on by default?! And it's not easy to find...

Grrrr the Notes redesign can't happen soon enough for me! Tho it will probably be six to twelve months after release before it's implemented here...

Lotus notes should be mothballed

I've forgotten about the joys of Lotus Notes until starting my latest contract. It's an absolute nightmare!

Here's a few of my favs:
- Shortcut for refresh view is F9 (the 'standard' refresh key of F5 is reserved to lock the lotus notes screen grrr)
- Printing support for meetings is horrendus - doesnt 'grow' any text areas that have scroll bars (ie more than 5 people at the meeting and it won't print them all out...)
- The calendar software is pretty ugly - never know what's gonna happen if you edit a meeting - might email everyone, might not email anyone of meeting changes. And occassionally drops one person and refuses to let me add them again...
- looks and feels like software from 1991.

I can't believe anyone is actually migrating TO notes rather than away anymore! As much as I hate outlook/exchange, it's a million times more user friendly than this.

The strangest lasagne...

Just had a 'individual' lasagne from the staff cafe at my new work, and it was kinda bizzare...
No cheese, No bechamel sauce. So it was dry, and the top layer of pasta was cooked solid. More like greasy mince between solid pasta wafers... mmmmmm

There is nothing worse...

... than sitting near someone at work that sniffs all day long. And they don't usually realise they're doing it. Eeuck!

--
posted via email

Jobserve rant

Jobserve is IMHO the UK's best job search site. This has nothing to do with the technology they use, but just because so many agencies post there and search the CV database. I think all the contracts I've ever had have been applied from jobserve, or the agent has seen my CV there.
However, it has a few shortcomings....

1. No spellchecker in job ads -> I've used the job posting functionality as a
'recruiter' before, and noticed this. It drives me crazy seeing basic technical terms spelt incorrectly in job ads - could be due to laziness or a genuine mistake on the agents behalf, or the agent not really knowing what they are writing. Today I saw 'Mogzilla'... If only they ran a basic spellcheck with a dictionary of standard IT industry terms! I had to write up my job ad's in Word to get it all spellchecked, then copy and paste into the job ad. I guess that won't help with agents who just totally get the context wrong alltogether tho - next time I see one of those I'll post it in.
2. CV database - I often get completely random email shots from agents who've just indexed something random in my CV (ie tested a product written in Delphi or something), and so I start getting totally random ads posted to me. Especially the permanent/contract role thing... This is really frustrating, as part of the Jobserve profile contains what job titles you want, and if you're after perm/contract/both. I don't know if this is the agencies re-indexing CV's and doing their own mailshots, or jobserve's cv indexing, but somewhere the job title and type is being totally ignored.
3. Random job results in the search - often I just get rubbish coming back... even tho it's filtered to UK, often get Australian jobs (not a huge issue, but annoying).
4. Links in the rss feed are often broken, or try to run another search rather than posting to the referenced job.

I do like the rss feed feature, but that seems to have different results to searching on the site - I use the same search terms, so perhaps they have a bug somewhere.

--
posted via email

Issue reporting styles in the real(?) world

My first real <rant/>...

So I've come across two major schools of thought when it comes to issue reporting...
School 1: for every bug/change/improvement, log a seperate issue
School 2: for related bugs/changes/improvements, log a single issue that contains all the related issues

My personal preference is for School 1. Why?

1. Bug Maintainence Time
Logging a issue with lots of issues in it is faster for administration - easier to close one bug, and resolve one bug to a developer.
Winner: School 2

2. Reporting
Logging seperate issues for each issue obviously means your reports will be accurate. If parts of the issue are fixed and not others in a version, its impossible to accuratley tally up the opened/closed counts against a version, or a person (ie bugs assigned per developer, bugs closed per developer etc). And even worse if the issue affects multiple 'components' or projects, then can't tell which areas have the most problems. Some systems enable time to be logged against tasks - estimates and actual time, and for future learning/planning, each problem/issue should have time logged seperatley allowing for better future planning. I've also come across sites where multiple issues that aren't even particularaly related are logged in a single issue (yeah, maybe they all happened during installation, but really some were installation bugs, others totally unrelated to installation, but a build issue instead).
Winner: School 1

3. Accuracy
Often if there's a large list of issues in one issue, some can get missed out (at spec, dev or test phase)
Winner: School 1

4. Parallel workflow
Assigning an issue containing lots of issues to one person means it wont show up in anyone elses work list until the first person is done/reassigned the issue. Seperating out each issue into it's own report means they can be worked on in parallel where possible, and not have to be passed from one to another.
Winner: School 1

Tools like JIRA are able to have 'sub tasks' - many small tasks logged seperatley, but grouped under a large task. Ie A group task called 'fix layout headers in all apps' - with a small subtasks for each application. This allows each subtask to be completed, reported etc seperatley, and also easily see the progress on the entire group of issues as a whole. Also tools that allow bulk editing make life easier for managers/developers etc to update multiple issues at a time, removing a lot of the administration time required.

Of course there needs to be some flexibility (ie if there are 5 spelling mistakes on a web page, then drop those into one issue, but spelling mistakes in different parts of the website need to be seperated out), but for the sake of simplicity and accuracy [speaking as someone who's been responsible for reporting and managing a change request system], logging seperate issues for each change is the way I would go. For a few extra minutes a day of administration time by your developers/managers, you'll be rewarded with a more accurate and realistic view of what's really going on in your change management process, and the overall quality of your products, assuming quality is something that is considered important in your overall product of course!

Another thing that's been bugging me is Issue ownership. I've worked at some sites where the Test Manager isn't particulary involved with issues after they've been logged. My philosophy is that the Test team are responsible for saying yay or nay to whether they consider a release is *OK*, so they own those issues raised, and should be involved with any planning around getting the issues fixed, changed, postponed, deleted etc. There are also sites where any old person (support, marketing, sales and other non-testers) have access to the issue/change management tools, so can raise issue, but then aren't considered responsible for ensuring those issues are dealt with, or confirming they are correctly resolved. If a bug is raised by a non-test team member, (i.e. it's usually been found outside a normal test cycle) it's my belief that someone from that team should be ultimatley responsible for verifying/confirming that issue is resolved to their satisfaction.