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.

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.

Jonathan Ive focused on design, again

As I’ve written about before, I assumed that Apple’s Jonathan Ive had his hands full with the completion of the design of Apple Park, and that was affecting the design and quality of Apple’s recent product offerings. This quote comes from bloomberg.com: “With the completion of Apple Park, Apple’s design leaders and teams are again reporting directly to Jony Ive, who remains focused purely on design,” Amy Bessette, a company spokeswoman, said Friday in a statement.