Getting Unstuck

It’s easy to get stuck, doing the same things. Doing something that’s suboptimal because there’s not time to invest in fixing the process, or something that used to be the best thing but is now a bit outmoded, a bit behind the times.

Here’s a list of things that have worked for me at different times:

1) Postmortems. Post iteration, if you’re working in iterations, or post release if not, look back and get a chance to rethink what went wrong or right.

2) Conferences and professional meetings. Interacting with colleagues who have solved the same problems you face in a different way provides new ideas.

3) Dedicating an hour a day at the beginning or end of the day for cleaning up those minor things that could be better, but that there might not be time to fix in the middle of a crisis. Incremental improvement is better than no improvement at all.

4) Go Crazy Day. Whatever name you give it, timeboxing a new technology exploration is a great idea.

5) Reading, and especially writing. This blog is partly to keep myself from getting stale. But when I’m not in a public posting mood, I have often kept a daily log of “one thing I learned today”. When I start feeling that there’s nothing to write, it’s time to shake myself up a bit.

I can't do all these things all the time, or even any of them all the time, but when I need a change, I know I have a set of tools. How do you keep yourself or your team out of a rut?

What makes a good bugtracking system?

Most bug tracking systems have built in reports that give certain views of the data -- all bugs currently in state "Open", for example. And then, it's reasonable to expect those reports to be customizeable: "all bugs currently in state Open that were created in July", for example. However sometimes we need metrics that need a little more digging around.

In a bugtracking system I recently used, it was extraordinarily difficult to create a report that would go back in history: "all bugs that have been moved to state Verified this past week" . (In this system "Verified" was not a terminal state, so there could be and usually were additional state changes after that.) Daily metrics reports of the bug database could reveal motion from one day to the next and could be aggregated to form some pretty charts. But that one missing report meant a lot of careful notetaking while I was fixing bugs so that I could report status on them myself.

For me, one of the marks of a really good bugtracking system is that I can get at the information in it in ways that the authors had not previously thought of but that turn out to be useful in the moment.

A blog restarted

I originally started this blog, But in Practice ..., to write down some thoughts and observations about software testing and software development practices. That was in 2006. Some fun years at a startup company that had me too busy for regular blogging intervened. Now, with another spin of the wheel, I find myself with time again to reflect and write about software testing.

My experiences in the field have led me to be something of a generalist. Test automation? Yes, sometimes that's the right thing and I can and have done that. Manual testing? Not always the wrong answer, either. Agile software development? Yes, but so many companies are using the word these days and I find it doesn't mean the same thing to everyone. And pure agile development doesn't fit every problem domain.

This blog is a place to reflect on the messy realities of software testing and how those activities -- filing bug reports, and deciding what and how to test and having difficult conversations with our many stakeholders, and tracking and measure what we do, and more -- fit in withthe underlying principles. The title of this blog reflects that endeavor. In theory, as the saying goes, theory and practice are the same, but in practice they're different. But In Practice ... explores those differences and finds in them the contributions that software test makes to creating great products.