quality

Use Case best practice: Test your Use Cases with real data

Quite often when I’m asked to review a UML “Use Case” that someone else has written, I ask “Have you tested your Use Case with real data?” Sadly, the answer is usually “no.”

I don’t know why people don’t do this, but they don’t, and it seems like a very logical thing — essentially a unit test for Use Cases.

Good design: Quantity leads to quality (and iteration speed is vital)

When I saw this tweet this morning:

[DOG MAGICIAN] think of a color, any color ... is it ... gray?

[OTHER DOG] oh my GOD

I knew that I loved the joke, but I didn’t like the presentation. I wanted to put the joke on Facebook, but I know that people like images more than they like text, so I made a second cup of coffee and began putting the text on an image.

The frustration of working with people who aren’t “A” Players (or don’t care)

Let me start by saying that I don’t know if I’m an “A” Player. In part, that definition depends (a) on what work I’m doing, and (b) who you compare me to. For instance, if you compare me to Linus Tourvalds as a Linux C programmer, I’m very clearly not an A Player. Shoot, I’m not even a player.

But if you were to judge me on other skills, I’d like to say that I’m at least a B Player in the things I care about. As I wrote in my book, A Survival Guide for New Consultants, my superpower as a programmer/analyst is empathy; I care about my work, and about my success and my client’s success. If you pay me $100,000 to do some work, I want you to make at least 2X or 10X or more from my work. I want my clients and sponsors to succeed.

Beyond that care, since I began paying attention to Apple and Jonathan Ive starting back around 2005, I’ve become more interested than ever in quality. When I work on something, I imagine that I’m either working with Mr. Ive, or that I’m going to have him review my work, and I want it to be impeccable.

Testing takes time, just like structural analysis takes time

“Testing takes time, just like structural analysis takes time. Both activities ensure the quality of the end product. It’s time for software developers to take up the mantle of responsibility for what they produce. Testing alone isn’t sufficient, but it is necessary.”

~ Neal Ford (as seen on this tweet)

UML Use Case quality: Questions to ask yourself when writing a Use Case

Table of Contents1 - Major points of my "User Logs In" Use Case2 - The "User Logs In" user story3 - Are my statements testable?4 - What I left out5 - User Stories, Use Cases, and Requirements6 - Back to the questions

I was just updating my Example UML Use Case diagram article and it occurred to me that if you're a Business Analyst, there are a couple of questions you can ask yourself as you write a Use Case (or User Story) that will help improve the quality of your writing. Two questions specifically come to mind:

  • What are the main points of this use case? (Which might also be phrased, "What points about this business process do I need to make sure everyone really agrees about?")
  • Are the statements I've written testable?

Seven benefits of automated GUI testing

Table of Contents1 - Benefits of automated GUI testing2 - Keys to automated GUI testing and continuous integration3 - Beware automated GUI testing software sales pitches and recorders

Introduction: I first wrote this article about automated GUI testing many years ago, but I find that it still holds today.

I just wrote most of the following note on the Apple Mac Java-dev mailing list, and I'd like to share it here as well, because I think it captures my thoughts on the benefits of automated GUI testing and GUI testing software.

I ran automated GUI tests part-time (4-6 hours per week) on a project with 8-12 developers, and saw some good benefits. True, in the 80/20 rule, 80% of the problems were due to UI changes and communication, like “We forgot to tell you we split the Name field into First Name and Last Name,” but with a good automated GUI testing tool, one test may fail, but the rest of the automated GUI test suite keeps running (see Fowler’s continuous integration). Furthermore, with a good GUI testing tool, something like this is also a minor change to get the test running again.

ScalaCheck custom generator examples

Table of Contents1 - Custom generators2 - Built-in ScalaCheck generators3 - How to use ScalaCheck generators4 - More ScalaCheck generators

Writing custom generators for ScalaCheck can be one of the more difficult and/or time-consuming parts of using it. As a result I thought I’d start putting together a list of generators that I have written or seen elsewhere. Unfortunately I can’t credit all the ones I’ve seen in other places because I google’d and copied them many moons ago, but I’ll give credit/attribution to all the ones I can.

Back to top

Custom generators

This is a combination of generators I wrote, and some that I copied from other places and may have modified a little:

Software development process standard operating procedures

Some long time ago I was working on a large software development project, and I wasn’t happy with either the quality or the velocity of our programming effort. So one night I sat down and tried to work out an activity diagram to show what our software development process needed to be, to improve both speed and quality. It turns out that a lot of this is just common sense, but for some reason or another team members would try to circumvent the process, which always led to more pain for everyone involved.