Using Jira for Test Tracking

I'm giving a brief talk tomorrow on using Jira for Test Tracking at the first California Atlassian User Group tomorrow. More details on the user group may be found here.

(update: here are the slides and they're also attached to the Atlassian page)

On the Naming of Protocols

Words to never use in your protocol name: "simple", "trivial", "lightweight", since the results never are.

Signs That You Are Not Comfortable With The Command Line

Some signs that you aren't as comfortable as you could be when using a command line. Drawn from observations over twenty years at many companies.

Runs all over the Tennis Court

To see what's in a directory, you type:

cd  very/long/path
ls

or even worse

cd very
cd long
cd  path
ls

This is the easy way:

ls very/long/path

Drives With Accelerator, Brake, Accelerator, Brake, ...

You start an editor to look at a file, then quit the editor to list the directory, then start the editor to look at the file again. Repeat. At least bring up another window and edit the file from there. Or browse the directory from inside your editor.

Tells Jokes With Too Much Detail

You type every character in file or directory names. Autocompletion comes with almost every shell and will do the typing for you.

Never Takes Elevators

You move around the command line only with the arrow keys. Sometimes doesn't even hold them down for repeat but instead presses the desired key many, many times. Keboard shortcuts to move around and delete larger blocks of text such as words not used.

Word Doesn't Play Nicely With Code

Don't cut and paste from Word or Outlook into Eclipse, Jira or any non-Windows application. Or if you do, then at least disable the smart-quotes stuff in Word How to disable smart quotes in word:

• Tools, AutoCorrect Options, AutoCorrect - uncheck all correct and capitalize boxes
• Tools, AutoCorrect Options, AutoFormat As You Type - uncheck all correct and capitalize boxes
• Tools, AutoCorrect Options, AutoFormat - uncheck all correct and capitalize boxes

Windows applications use a character set that is not UTF-8, which is what is used by most browsers, editors, etc. This is usually not a problem since the Windows character set is mostly compatible, but if you have smart-anything enabled inWord (smart-quotes, auto-format etc) then character such as double quotes and hyphens get quietly converted into characters that look nicer on the screen but don't work in source code.

The following pipeline will tell you which Java files contain non-ASCII characters. These might be valid instances of non-ASCII characters, but they ought to be checked.

[mdoar@toolsdev Projects]$ find SystemServices/ -name "*.java" | xargs perl -nwe 'print "$ARGV\n" if /[^[:ascii:]]/'  | sort | uniq -c | sort -rn | more
19 SystemServices/src/java/com/packetmotion/sysservice/exception/SystemException.java
...

To see the line numbers in each file:

[mdoar@toolsdev Projects]$ find SystemServices/ -name "*.java" | xargs perl -nwe 'print "$ARGV:$.\n" if /[^[:ascii:]]/'

Some Different Approaches to Integration

"Customers buy this as a single product, so think of it as a single product!"

The recommended approach if you want to make a change that you know will break other people's code (and it's your responsibility to test for that as far as possible), then you should communicate (not a one-way email) with the people involved and agree which of the methods below you are going to use to minimize disruption to the rest of the organization.

Example

Vivek wants to remove a method named getFunky() from a class used by the Client, and maybe by other components.

1. He makes his changes in his sandbox and checks that they work, then builds as much of the whole product as he can.
2. He notices that as expected he will break the Client
3. Just to make sure, he also looks at the Javadoc or uses Eclipse to identify other users of the method, and finds out that the Manager now uses getFunky too. Good thing he checked!
4. He communicates with two developers who are comfortable with changing the affected code in the Client and Manager, and together they decide how to make the necessary changes (see the choices below for some ideas)
5. Just to repeat the obvious - an email sent to a group and gets no responses is not communication, it's just a feeble excuse at teamwork. Integration requires two-way exchanges.
6. The changes are committed and life moves on.

No prizes for guessing that I don't think much of approach #2 (Break the Build), but if you decide to do this, make sure that you mail all-eng@example.com so that everyone else in the team is aware and isn't inconvenienced by the broken build.

Handy tip: your local address book may show who is in each email alias

Different Approaches

1. Don't remove the existing functionality, just add the new functionality

Pros: Nothing should break

Cons: Can be fiddly to get right, leads to overly complex code that eventually needs removing anyway

2. Check it in, break the build, and wait for other people to fix it

Pros: Quick and easy, for you at least.

Cons: Can bring development for the rest of the company to a halt. Not a career-enhancing approach if used too often.

3. Send out the changed files in email for people to develop against before you commit them

Pros: Simple

Cons: You may miss some, tedious for people to use. Generally, a bit 20th century.

4. Send out a patch for all the changed files

Pros: less likely to miss files, a bit easier to apply

Cons: harder to send multiple changes as multiple patches

5. Create a private branch, make your changes there, tell people which directories to use the branched version for.

Pros: Easier to continue working on your changes and for other people to accept them when ready

Cons: A bit more work to set up the branch in the first place

What do I look like?

Here I am at the beach avoiding being photographed, and also looking at a Tintin book with my elder son Jacob.